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END OBJECT; 


Readable, compact language with multiple 
inheritance, strong typing, and dynamic binding 



Forms, graphs, and icons defined through the 
editor-no programming 


After you’ve tried new MODSIM II 
other object-oriented languages will seem primitive 

Free trial and, if you act now, free training 


M ODSIM II is a modern 

high-level, object-oriented 
language with these important 
benefits: 

• Object-oriented programming. 

The powerful mechanisms that 
help you develop structured, 
easily maintainable code. 

• A compact, readable language. 
Your programs are at least 25% 
smaller than equivalent C + 4- 
programs and they are easier to 
read. 

• Symbolic debugger. Error detec¬ 
tion and correction are simplified 
through steptracing, multiple 
breakpoints, and data viewing. 

• Graphics and animation. You 
easily lay out your graphical in¬ 
terface with no programming. 

• Standardization across com¬ 
puters. Your development invest¬ 
ment is preserved when you 
change computer types. 

• Simulation. All the features you 
need to do simulation and auto¬ 
matically collect statistics are 
available if you need them. 

With these benefits, the time and 
cost you need to develop programs is 
sharply reduced. 


Free trial offer 

The free trial contains everything 
you need to try MODSIM II on your 
computer. Try the language, the 
quality and the timeliness of our sup¬ 
port, and our documentation and 
training-everything you need for a 
successful project. 

We’ve been providing software 
and support for 29 years-we’ll be 
here when you need us. 

Computers with MODSIM II 

MODSIM II® is available for all 
popular computers. 

Charter User Group benefits 

CACI is now organizing a MOD¬ 
SIM II Charter User Group. Mem¬ 
bers receive a reduced price, early 
releases, and other benefits. 

For a limited time we also include 
free training. Call today to avoid 
disappointment-class size is limited. 

For immediate information 

In the US, call Hal Duncan at (619) 
457-9681, or Fax (619) 457-1184. In 
the UK and Europe, call Nigel 
McNamara, in the UK, on (081) 
332-0122, Fax (081) 332-0112. In 
Canada, call Peter Holt on (613) 
782-2474, Fax (613) 782-2202. 


Rush information on MODSIM II. 

Free trial-leam the reasons for the 
growing popularity of MODSIM II. 

Charter User Group offer-return the 
coupon today and we will include a 
free course worth $950. 





Telephone_Fax 


Computer_0/S 


□ Send details on your University Offer 

Return to: IEEE COMp 

CACI Products Company 

3344 North Torrey Pines Court 

La Jolla, California 92037 

Call Hal Duncan at (619) 457-9681 

Fax (619) 457-1184 

In the UK or Europe: 

CACI Products Division 
Palm Court, 4 Heron Square 
Richmond, Surrey TW9 1EW, UK 
Call Nigel McNamara on (081) 332-0122 
Fax (081) 332-0112 
In Canada: 

CACI Products Division 
200-440 Laurier Avenue West 
Ottawa, Ontario KIR 7X6 

Call Peter Holt on (613) 782-2474 
Fax (613) 782-2202 


MODSIM II is a registered trademark and 
©1991 CACI Products Company 


























COMPUTER 


April 1991 Published by the IEEE Computer Society Vol. 24, No. 4 


ARTICLES 


The Evolution of Instruction Sequencing 

Robert F. Krick and Apostolos Dollas 

Instruction sequencing is complicated by interdependencies between instructions. High-performance systems use 
a number of strategies to address these interdependencies and improve performance. 

17 Autonomous Robotic Inspection and Manipulation Using Multisensor 
Feedback 

Mongi A. Abidi, Richard O. Eason, and Rafael C. Gonzalez 
At the core of a robotic system is its capability to acquire, fuse, and interpret multisensory data, such as vision, 
range, and touch, to generate appropriate actions to perform a given task. 

33 Object-Oriented Database Management Systems: Concepts and Issues 

Elisa Bertino and Lorenzo Martino 

Object-oriented database technology combines the expressive power of programming languages with effective 
support for persistent data typical of database management systems. 

49 Reliability Modeling: An Overview for System Designers 

Andrew L. Reibman and Malathi Veeraraghavan 

Approaches for predicting system reliability include use of parts-count, combinatorial, and state-space models. A 
case study of a fault-tolerant system illustrates the process. 

59 Interactive Systems: Bridging the Gaps Between Developers and Users 

Jonathan Grudin 

Three paradigms illustrate the framework for interactive systems development projects: competitively bid, 
product development, and in-house/custom development. 





COMPUTER 

















70 Standards 

Preparing for EC 1992 
registration 

72 Update 

Stanford takes programming prize; Corbato receives Turing award 

74 Computer Society News 

Sidney Fernbach dies; Carroll, Engel delegate-director nominees; 
Task force solicits participation 

76 New Products 
84 Product Reviews 

Hand-held computers; White Knight; Norton Utilities 


Cover photo and design: 

Chris Martin, Design & Direction 


In the next issue 

Real-time systems 


81 IC/Microsystem Announcements 
93 Conferences/Calendar/Call for Papers 
110 Book Reviews 
112 Open Channel 

Confessions of a used-program salesman 


Career Opportunities, 106; Computer 
Society Information, 32; Membership 
Application, 83; Change of Address Form, 
69; Advertiser/Product Index, 80; Reader 
Service Card, 80A 



April 1991 




















New computer science journals from Wiley— 
from theory through research to practice 


International Journal of Optical Internetworking: Research and 

Computing Experience 


Editors: J.A. NEFF, USA; G. LEBRETON, France; 

V. MOROZOV, USSR; and Y. ICHIOKA, Japan. 

The concept of optical computing is challenging existing notions 
of the speed at which information can be processed and the effi¬ 
ciency with which it can be stored. The implications of this 
rapidly expanding branch of applied optics are far-reaching and 
impact on many areas of computing and electronics including 
emergent technologies such as artificial intelligence, machine 
vision, neural networks, and supercomputers. The Interna¬ 
tional Journal of Optical Computing is designed to meet the 
clear need for a single source of information on current 
research and developments in optical computing technology. 
This includes processing techniques based on electro-optics, 
magneto-optics, acousto-optics, and non-linear optics in 
addition to classical optics. Coverage extends to algorithms, 
architectures, components, devices, materials and techniques. 
Volume 2 (1991) Quarterly 


The Journal of Visualization and 
Computer Animation 

Editors-in-Chief: N. MAGNENAT THALMANN and 

D. THALMANN, Switzerland. 

Associate Editors-in-Chief: T.L. KUNII, Japan; 

E. CATMULL, USA. 

The advent of high-powered computers and sophisticated 
software has made it feasible for researchers in all fields to vis¬ 
ualize structures and processes previously invisible except to 
the imagination. Nowadays, visualization and computer anima¬ 
tion are closely linked: visualization alone, without animation is 
of limited interest in many contexts; and animation is but the 
fourth dimension of visualization. The Journal of Visualization 
and Computer Animation serves to highlight this link. Published 
quarterly each issue contains research papers, film case 
studies, critiques and software reviews plus news of confer¬ 
ences and seminars. 

Volume 2 (1991) Quarterly 


Journal of Software Maintenance: 
Research and Practice 

Editors: K.H. BENNETT, UK; M.A. COLTER, USA. 

The challenge of sustaining the viability of software during its 
lifetime (of perhaps several decades) represents a major con¬ 
cern. This journal is devoted to this activity, which is concerned 
with the management of change. The editors’ aim is to convey 
the results of academic research and practical experience into 
the computing community. Topics covered include: software 
evolution lifestyles, software maintenance management, tools, 
environments, metrics and productivity methods, quality 
assurance, theory of software maintenance, and the impact on 
maintenance of new software practices. 

Volume 3 (1991) Quarterly 


Editor-in-Chief: D.E. COMER, USA. 

Editors: R.E. DROMS, USA; D.L. ESTRIN, USA; 

L. SVOBODOVA, Switzerland. 

Experimental research and practice are very important to 
understanding internetworking and interoperability issues, and 
finding workable solutions. Many studies of experimental 
nature have been performed in the Internet environment. The 
emerging OSI networks offer a new platform for experimental 
research but the results of this work have been reported 
primarily in technical reports, RFCs, and in various conference 
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The Evolution 
of Instruction 
Sequencing 


Robert F. Krick and Apostolos Dollas 
Duke University 


I nstruction sequencing and data fetch¬ 
ing are fundamental to the operation 
of von Neumann architectures. Al¬ 
though we limit our discussion to instruc¬ 
tion sequencing, we do not mean to disre¬ 
gard the importance of data-fetching issues 
and methodologies. Indeed, readers should 
remember the clause “subject to the avail¬ 
ability of data” during the rest of this arti¬ 
cle. Works on data fetching should also be 
read with a corresponding clause on in¬ 
struction availability. 

We begin by outlining the three distinct 
phases that constitute the sequencing of 
each instruction: 

• determining the memory address that 
contains the instruction, 

• fetching the instruction from memory, 
and 

• executing the instruction. 

The minimum time required for each of 
these phases is t h t M , and t E , respectively (see 
Instruction sequencing sidebar for explicit 
definitions of these parameters). In the 
following sections, we trace the evolution 
of instruction sequencing with attention to 
the influence of the available technology 
on these parameters and the resulting de- 
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Instruction sequencing 
is complicated by 
interdependencies 
between instructions. 
High-performance 
systems use a 
number of strategies 
to address these 
interdependencies 
and improve 
performance. 


sign decisions. Rather than discussing ab¬ 
solute system performance, we examine 
the interrelationship of these critical pa¬ 
rameters (see Glossary for definitions of 
general terms). 
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Memory bandwidth 

Prior to the commercial introduction of 
semiconductor memory, a significant im¬ 
balance existed between the values of 
and the magnetic core memory cycle t M 
(typically t M > 10 ■ t,). Bipolar transistor 
technology and higher degrees of pipelin¬ 
ing had reduced the values of t, and t E but 
the value of t M for magnetic core memory 
technology did not decrease at the same 
rate. To realize higher instruction-execu¬ 
tion rates in systems with this imbalance, 
designers developed enhanced memory 
organizations. 

Since designers could not readily de¬ 
crease the memory cycle time, they in¬ 
creased the instruction bandwidth by 
fetching more than one instruction from 
memory at a time. More specifically, the 
number of these instructions n t had to be 
sufficient for continuous operation of the 
processor: 

n,>t M 11, 

Designers employed wide words and 
interleaving to achieve the required in¬ 
struction bandwidth. 










In memory words that contain more 
than one instruction, each memory refer¬ 
ence can fetch multiple instructions. In the 
fifties, von Neumann’s IAS machine and 
the IBM 7094 fetched multiple instruc¬ 
tions with a single memory reference. The 
IAS machine stored two instructions in 


each word of memory. In comparison, the 
IBM 7094’ s 72-bit-wide memory let it read 
two 36-bit, single-word instructions si¬ 
multaneously. 

The technique of interleaving also pro¬ 
vides high bandwidth, but with fewer con¬ 
straints than in memories that allow access 


of multiple instructions with a single refer¬ 
ence. To employ interleaving a designer 
must partition the address space across m 
different memories (called banks) to allow 
a maximum of m independent, concurrent 
memory accesses (one in each bank). The 
banks can provide instructions in consec- 


Instruction sequencing 

The temporal relationships that exist between the three 
phases of an instruction are inherently sequential. Before a 
processor can execute an instruction, it must fetch the in¬ 
struction from memory. Before this operation can occur, the in¬ 
struction pointer must be updated. Consequently, we can ex¬ 
amine the memory-processor interrelationship for instruction 
sequencing in the context of a “producer-consumer” model. 

In this model, the rate at which the processor consumes 
(executes) instructions cannot exceed the rate at which in¬ 
structions are produced (fetched) from the memory. The pro¬ 
cessor can achieve peak performance only when it does not 
have to wait for memory to provide the instruction required for 
execution. However, the producer (memory) does not operate 
independently of the consumer (processor). During the exe¬ 
cution phase of each instruction, the processor determines 
the memory location of the next instruction to be executed. 
Execution of an instruction such as a conditional branch can 
affect the address of the next instruction, and the memory re¬ 
sponse to some instruction requests affects the availability of 
an instruction for execution. Therefore, interaction must occur 
between the producer and consumer in this model. 

Based on the method used to specify the next instruction 
for execution, we classify the instructions of conventional ar¬ 
chitectures as computational or branch. The former (such as 
add or load) execute sequentially when they are stored in 
consecutive memory locations. In contrast, branch instruc¬ 
tions alter the control flow of the program from sequential ex¬ 
ecution. Many branch instructions contain the address of the 
instruction following the branch, or the target , whereas the 
target for other instructions (like return) is not defined explicit¬ 


ly within the instruction itself. Instruction sequencing for pro¬ 
grams without branches would be trivial, as the producer and 
the consumer would not interact within the model. Unfortu¬ 
nately, instruction sequences without branches are typically 
quite short. A recent study shows that the mean number of in¬ 
structions between changes in control flow (branches that are 
taken) is seven and that the median is four. 

Figure A shows the relationship between the request for in¬ 
structions and their execution, as well as the interrelationship 
of the critical timing parameters, namely f/, t M , and t E . We de¬ 
fine the parameters t M and t E respectively as the time it takes 
to fetch an instruction from memory and the execution time of 
an instruction. The parameter f, in a nonpipelined system is 
simply the time to either load or increment a counter that is 
used as the address for the next instruction. 

The specification of t, in a pipelined system is somewhat 
more complex. In these systems, subsequent instructions can 
be requested before the execution of the previous instruction 
has been completed, and, in this case, f/ remains unchanged 
from the definition in the nonpipelined system. Conditional 
branch instructions, however, can alter the request of subse¬ 
quent instructions in a pipelined system. Under these circum¬ 
stances, f, corresponds to the time required to complete exe¬ 
cution of the conditional branch instruction and includes both 
t M and f E for that instruction. In practice, designers use the 
shorter path for f, to determine an upper bound for the in¬ 
struction-execution rate. 

Figure B shows the execution of the instruction sequence 
{/, j, k, I} in a simple pipeline. Here t M is balanced with t E . In 
the absence of conditional branches, the processor can spec- 


Branch taken/not taken 


P. 



instruction sequencing. 
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utive memory locations in a round-robin 
manner, but, due to its width or alignment, 
an instruction can also span the boundary 
between interleaved banks. The IBM 7094 
II was one of the earliest commercial ma¬ 
chines to feature interleaving. 

Although the raw bandwidth of an m- 


word-wide memory can match the band¬ 
width of an m- way interleaved memory, the 
two methods are not equivalent. Consider 
the fetch of two instructions that are re¬ 
quested at an interval of tj. In an inter¬ 
leaved memory, each fetch requires t M to 
complete if the instruction addresses differ 


by an exact multiple of m. This occurs be¬ 
cause a single bank is accessed repeatedly. 
In the best case, however, each instruction 
address for a sequence of instructions ref¬ 
erences a different bank, so that after an 
initial t M , the instructions arrive at t, in¬ 
tervals. With an m-word-wide memory, the 


.. ,w : 

ify the address of the next instruction for execution at the be¬ 
ginning of the execution stage for each instruction. The rate 
' at which the processor executes instructions matches the 

rate at which memory produces them. 

Improved peak instruction-execution rates can result from 
a more advanced technology or a higher degree of pipelin¬ 
ing. The two speed-up methods are interrelated. The value 
7 of t M shown in the pipelines of Figure C is a factor of three 
larger than the value of f,. In case (2) the value of t E is also 
three times larger than f,. For these pipelines to operate con¬ 
tinuously with a value of f, smaller than t M or t E , the following 
conditions have to be met for peak execution rate: 

(1) The rate at which memory produces instructions 
matches the rate at which the processor requests instruc¬ 
tions (fetch rate equals request rate). 

(2) The prefetching of an instruction begins sufficiently in 
advance of its need by the execution unit (degree of looka¬ 
head). 

(3) The simultaneous execution of multiple instructions by 
the execution unit does not lead to any conflicts in the use of 
the resources of the execution unit (execution rate). 

Many implications arise from these three conditions. First, 
memory must satisfy multiple accesses simultaneously. In the 
case of the second condition, the degree of lookahead would 
be minimal for a fast memory. Computer performance is gen¬ 
erally limited by a memory-access bottleneck (memory is nev- 
I er too fast for a processor). In deep pipelining such as shown 

in Figure C2, the third condition may not be trivial to satisfy, 
and either hardware or software methods must be employed. 

A cursory examination suggests that the imbalance be¬ 
tween t M , t h and t E is the result of poor design. However, 
these parameters are determined by enabling technologies, 
and their values cannot be arbitrarily specified by the design¬ 
er. In practice, the slowest of the parameters t M , t h and t E is 
a bottleneck and determines worst-case performance, but an 
appropriate organization can operate in many situations at a 
rate determined by the fastest parameter. For example, the 
imbalance between f M and f,for both pipelines in Figure C 
can be addressed by the use of cache memory. The low la¬ 
tency of a cache decreases the difficulties associated with 
supplying instructions from main memory at the rate neces¬ 
sary for peak performance. 

Interinstruction dependencies associated with branch in¬ 
structions become a dominant factor in limiting the rate at 
which instructions can be sequenced. These dependencies 
can lengthen the execution time of branch instructions in two 
situations: 

• The conditions specified by a conditional branch instruc¬ 
tion must be evaluated to determine if the branch target 
should be taken. 


• The branch target address is in either a data register or a 
memory location. In this situation, the possible values for the 
branch target cannot be determined prior to execution. These 
dynamic branch targets occur less frequently than static 
branch targets that are defined prior to execution. For example, 
the branch target for a conditional branch instruction is static, 
whereas a return from subroutine uses a dynamic target. 

Any instruction-sequencing scheme that initiates the execu¬ 
tion of additional instructions without waiting for these depen¬ 
dencies to be resolved must prevent these instructions from 
irreversibly changing the state of the machine before the 
branch target is positively identified. 



t M , t„ and t E : t, = t M ! 3 = t E (1); and t, = t M /3 = t E /3 (2). 
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first access also takes t M \ during that ac¬ 
cess, m words are fetched from memory. 
Therefore, any instructions from the group 
of m words are already fetched, and suc¬ 
cessive requests within the group complete 
essentially as fast as they can be issued 
(that is, at intervals tj). Requests from dif¬ 
ferent groups, however, each take t M to fetch, 
unlike the case in interleaving. 

Table 1 shows the various combinations 
of memory width and interleaving used to 
satisfy the range of instruction bandwidth 
requirements in the IBM System/360 se¬ 
ries. From 1965 through 1967 — when 
these models first shipped — the memory 
cycle time for the magnetic core was re¬ 


duced by less than a factor of three. Never¬ 
theless, a wider memory path, a higher 
degree of interleaving, and a shorter pro¬ 
cessor cycle time increased the maximum 
memory bandwidth by a factor of over 300 
between Models 30 and 91. (None of the 
systems listed in the table used cache mem¬ 
ory.) Because the higher performance 
models in this group could not use the 
maximum memory bandwidth as effec¬ 
tively as the lower performance models, 
the potential performance improvement was 
not fully realized for real programs. 

It is easy for a designer to provide raw 
bandwidth with these enhanced memory 
organizations. These organizations, how¬ 


ever, become increasingly inadequate as 
the frequency of branch instructions grows, 
because the target of a branch instruction is 
not known until after the branch instruc¬ 
tion has been fetched. Supplying the in¬ 
structions ultimately required by the pro¬ 
cessor is a difficult problem that cannot be 
solved by simply increasing bandwidth. 

Instruction buffers 

When highly pipelined systems execute 
sequential code, the address of the instruc¬ 
tion being referenced by memory can be 
well ahead of the address of the executing 
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Branch spreading — This technique explicitly splits 
each conditional branch instruction into two disjoint instruc¬ 
tions: one that modifies the condition codes and another 
that loads the branch target. When independent instructions 
are located between these two distinct instructions, the 
evaluation of the condition codes no longer limits the speed 
at which the branch target can be loaded. 

Branch target — This term refers to the address of the 
next instruction to be fetched for execution following the 
branch. 

Cache hit — In this situation, the cache contains the in¬ 
struction for the address specified by the processor, and 
the full latency of a main memory access is not incurred. 
The cache hit ratio is the number of hits normalized to the 
total number of references. 

Delayed branches — With this technique, one or more 
slots exist immediately after each branch instruction. The 
instructions in these slots are executed unconditionally 
while the branch target is determined and the next instruc¬ 
tion is fetched from memory. Reorganizing the code prior 
to execution usually fills these slots with useful instruc¬ 
tions. 

Loop unrolling — In the execution of a small loop, one 
can sometimes reduce the overhead associated with 
branch instructions if some information about the number of 
loop iterations can be determined prior to execution. In loop 
unrolling, the computational instructions in the loop are du¬ 
plicated many times so that more work is done for each iter¬ 
ation and fewer iterations of the loop are required. 

Orthogonal instruction set — This type of instruction 
set contains identical addressing modes for each instruc¬ 
tion. Although RISC processors have few addressing 
modes, their orthogonal instruction sets enable common bit 
fields within each instruction (for example, source registers) 
to control the hardware directly and eliminate the need for a 
dedicated stage for instruction decoding. 

Pipelining — This hardware technique allows the execu¬ 


tion of multiple instructions at a given time. Flip-flops or regis¬ 
ters between each successive stage of logic preserve the re¬ 
sults from the previous stage of execution. 

Reservation station — To support the dynamic schedul¬ 
ing of instructions for execution (potentially out of order), 
each functional unit within a processor has a set of registers 
to hold operands, results, and control information. Although 
not accessible by the programmer, these registers eliminate 
some of the bottlenecks associated with a central register file. 

Static vs. dynamic — Static means prior to execution, 
while dynamic means during execution. 

Straight-line code — This term refers to a sequence of in¬ 
structions located in consecutive memory locations. 

Subroutine in-lining — The overhead associated with 
calls and returns for short subroutines can often exceed the 
execution time of the subroutine. To eliminate this overhead, 
the subroutine code is duplicated where the subroutine is 
called, which makes the execution of call and return instruc¬ 
tions unnecessary. The support of macros in some high-level 
languages produces equivalent results. 

Superscalar — This hardware-based technique can simul¬ 
taneously initiate the execution of multiple independent in¬ 
structions. 

Vectorization — This process replaces dtetinct instructions 
that operate on multiple data items of the sam^ type with vec¬ 
tor instructions to produce equivalent results with higher per¬ 
formance. Machines with hardware support for vector opera¬ 
tions (like Cray computers) can perform a computation for 
every element in a vector with the execution of a single in¬ 
struction. The higher degree of pipelining possible for vector 
computations leads to a substantial performance improve¬ 
ment in comparison to the corresponding sequence of scalar 
instructions. 

Virtual cache — Virtual addresses access this cache to 
avoid the time-consuming translation from a virtual to a physi¬ 
cal address. 
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Table 1. Characteristics of models in the IBM System/360 series. 


Model 30 

40 

50 

60 

62 

65 

70 

75 

91 

tj (ns) 1,000 

625 

500 

250 

250 

200 

200 

195 

60 

t M (ns) 2,000 

2,500 

2,000 

2,000 

1,000 

750 

1,000 

750 

750 

Interleaving None 

None 

None 

2-way 

None 

2-way 

2-way 

4-way 

16-way 

Memory width (bytes) 1 

2 

4 

8 

8 

8 

8 

8 

8 

Maximum memory 0.5 

0.8 

2 

8 

8 

21.3 

16 

42.6 

170 

bandwidth (Mbytes) 











instruction. This prefetching of instruc¬ 
tions allows slow memory to keep up with 
a fast processor, especially when the 
memory bandwidth is adequate. Branch 
instructions, however, disrupt the se¬ 
quencing of instructions from consecutive 
memory locations. In terms of the three 
previously defined parameters, branch in¬ 
structions degrade performance because tj 
becomes a function of both t E and t M . Be¬ 
cause a branch instruction modifies the 
instruction pointer, the memory access for 
the target instruction must wait for execu¬ 
tion of the branch instruction to complete. 
Execution times for branch instructions 
and the memory latency both affect the 
instruction-sequencing rate. Unfortunate¬ 
ly, decreasing the cycle time of main 
memory has not been economically viable, 
and reducing the execution time of a branch 
instruction has not always been feasible. 
However, using instruction buffers and more 
advanced instruction prefetching can im¬ 
prove performance. 

A hardware-based first-in, first-out queue 
with simple shift registers can form the 
basis for an instruction buffer. This buffer 
decouples fetch and execute operations for 
each instruction. The processor shown in 
Figure 1 contains an instruction buffer that 
separates the I-unit (for fetching instruc¬ 
tions) from the E-unit (for executing them). 
The I-unit fills the instruction buffer on 
one end and the E-unit takes instructions 
from the buffer on the other. Processor 
performance is degraded when the next 
instruction required by the E-unit is not in 
the instruction buffer. 

To prefetch instructions, the I-unit an¬ 
ticipates upcoming instruction-pointer 
values. For example, the I-unit of the Intel 
8086 simply prefetches instructions from 
the addresses that follow the current in¬ 
struction pointer. Since instructions may 
take several cycles to complete, memory 
has sufficient time to provide instructions 
for sequential code. The 8086 instruction 


buffer is flushed after branches; however, 
flushing the buffer is not a requirement and 
does not occur in some other architectures. 

A more sophisticated I-unit with suffi¬ 
cient decoding capability can recognize 
the difference between computational and 
branch instructions. It can also identify 
branch instruction targets. The unit can 
prefetch the instructions from a statically 
defined target of an unconditional branch 
instruction or one of the statically defined 
targets of a conditional branch instruction. 
Both cases improve performance at a very 
low cost. 

Prefetching became the dominant issue 
in instruction sequencing by the mid-1960s. 
The sophisticated I-units from that period 
appear in such systems as the Control Data 
CDC 6600 1 and the IBM 360/91. 2 

The CDC 6600 contained an I-unit of 
moderate complexity, while the 360/91 
featured one of the most sophisticated I- 
units ever developed. Both systems initiat¬ 
ed a new instruction in every cycle when 
operating at peak performance. They also 
featured a variety of functional units to 
support the concurrent execution of multi¬ 
ple instructions. These designs demon¬ 
strated the desirability of decoupling the 


instruction request logic from the instruc¬ 
tion-execution logic. 

First introduced in 1964, the 6600 had a 
magnetic core main memory with a 1- 
microsecond t M cycle and 32-way inter¬ 
leaving. The memory bandwidth was suffi¬ 
cient to produce a new instruction for 
execution every 100 nanoseconds ( t,), and 
an instruction buffer consisting of eight 
60-bit words improved performance. With 
a 15-bit minimum instruction size, the I- 
unit could fill the instruction buffer with as 
many as 32 sequential instructions. These 
instructions were prefetched from consec¬ 
utive memory locations using the Program 
Address Register. In the absence of inter¬ 
instruction conflicts, one of the 10 func¬ 
tional units in the E-unit consumed an 
instruction for execution every 100 ns. 
These nonpipelined functional units exe¬ 
cuted an integer instruction within 400 ns, 
allowing up to four integer instructions to 
be executed concurrently in four function- 

Because the 6600 held all instructions 
for short loops in its instruction buffer, the 
I-unit did not have to fetch instructions 
from main memory during the execution of 
these loops. The time necessary to execute 
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a branch instruction with a statically de¬ 
fined target included 

• using a functional unit to evaluate the 
conditions for the branch to be taken, 

• determining whether the instruction 
buffer contained the instruction at the 
target address, 

• retrieving the target instruction from 
either the instruction buffer or main 
memory, and 

• passing the next instruction through 
the pipeline stages of the I-unit before 
the instruction was dispatched to a 
functional unit in the E-unit. 

The first two operations were performed 
in parallel, and, after they completed, the 
remaining two were performed sequen¬ 
tially. The instruction following a branch 
instruction could be initiated in 800 to 900 
ns when the target of the branch instruc¬ 
tion was statically defined and the in¬ 
struction buffer contained the instruction 
at the target address. Otherwise, the in¬ 
struction buffer was flushed. Fetching the 
instruction from main memory required 
an additional 600 ns (barring any access 
conflicts). In comparison to the 200 ns 
needed to access the instruction buffer, a 
read from main memory consumed 800 ns 
of the 1-p.s main memory cycle. The 
overall scheme was very successful, and 
the instruction buffer performance pleased 
users who hand-coded scientific applica¬ 
tions. 

When it was announced in 1965, the 
IBM 360/91 included a number of techni¬ 
cal innovations. It could hold eight 64-bit 
words, and the instruction buffer could be 
frozen to support small loops. In contrast to 
the 6600, the functional units within the E- 
unit were pipelined. The 360/91 could dis¬ 
patch interdependent instructions by using 
tagging and forwarding mechanisms (To- 
masulo’s algorithm) to ensure logically 
correct execution. 2 Instructions with no 
interdependencies could be executed out 
of order on the basis of available functional 
units. Because of its elegance and power, 
Tomasulo’s algorithm is still a subject of 
research and enhancement. 

Even by current standards, the 360/9l’s 
I-unit support for conditional branch in¬ 
structions is very sophisticated. A signal 
from the E-unit indicated whether any ex¬ 
ecuting instructions could change the 
condition codes. Although the I-unit could 
not determine whether the target of a con¬ 
ditional branch instruction would be taken 
until the condition codes were valid, this 
unit took actions to reduce the execution 



Made feasible by IC 
technology, a small, fast 
memory known as a cache 
greatly simplified the 
instruction-sequencing 
requirements of the I-units. 


time of conditional branch instructions re¬ 
gardless of the eventual outcome. 

The I-unit fetched two instructions from 
the address specified by the (statically de¬ 
fined) target of the conditional branch in¬ 
struction and stored them in a separate 
instruction buffer. If the conditional branch 
instruction was taken, execution continued 
without the penalty of a full main memory 
access (although the instructions from the 
buffer had to be decoded). Furthermore, 
the instructions that sequentially followed 
a conditional branch instruction (that is, 
the branch-not-taken case) were also re¬ 
quested from memory. Fetched instruc¬ 
tions were decoded by the I-unit and awaited 
execution pending the evaluation of the 
conditional branch instruction. However, 
when the branch was not taken, the fetch of 
an unused target could delay instruction 
fetches on the branch-not-taken path. 

The instruction buffer dampens small 
variations in the effective memory band¬ 
width and the instruction-execution rate. 
Major progress in instruction prefetch log¬ 
ic, its decoupling from execution logic, 
and the use of branch-target instruction 
buffers occurred in the sixties. 

Caches 

Made feasible by IC technology, a small, 
fast memory known as a cache greatly 
simplified the instruction-sequencing re¬ 
quirements of the I-units. To attain a peak 
execution rate of one instruction per cycle, 
the cache memory must have a cycle time t c 
less than or equal to t,. As a result, caches 
can produce instructions at arate that achieves 
peak processor performance for kernels of 
code larger than small loops. First incorpo¬ 
rated into high-performance computer sys¬ 
tems in the late sixties, caches remain a cost- 
effective technique for improving 
performance and are widely used today. 


The IBM 360/85, which followed the 
360/91, was the first commercial system to 
feature a cache memory. In comparison to 
the 360/91, the 360/85 had a 33 percent 
longer clock period (80 instead of 60 ns) 
and less than 40 percent of the maximum 
main memory bandwidth. Nevertheless, the 
use of a 16-kilobyte cache in the 360/85 
resulted in performance for integer appli¬ 
cations that equaled or exceeded that of the 
360/91. 

To sequence instructions in CDC’s sub¬ 
sequent 7600 model, designers combined 
the features of an instruction buffer with 
those of a cache. Although the I-unit still 
prefetched instructions, each of the 12 60- 
bit words in the instruction buffer had an 
additional field to store the 18-bit memory 
address corresponding to the prefetched 
instruction. Using fully associative storage 
for these memory address fields allowed 
each change in the program counter value 
to select any instruction in the buffer with 
equal access time. However, if the buffer 
did not contain the required instruction, the 
oldest instruction in the buffer was replaced 
by the instruction accessed from main 
memory. With the inclusion of the memory 
address field, instructions in the buffer 
were no longer required to come from con¬ 
secutive memory locations. This approach 
provided greater flexibility in capturing 
short loops than the method employed in 
either the 6600 or the 360/91. 

As in the 7600, designers of the Cray-1 
used the term instruction buffer for its 
small, fast instruction memory, even though 
it also contained memory addresses for 
associative comparisons. Each of the four 
128-byte buffers could contain as many as 
64 instructions from consecutive memory 
locations. The 16 most significant bits of 
the 22-bit address for all instructions within 
a single buffer were identical; thus, the 
contents of the buffers could not overlap. 
Because only four 16-bit addresses (one 
for each instruction buffer) had to be com¬ 
pared to determine if any buffer contained 
the requested instruction, the associative 
search could be performed quickly. How¬ 
ever, a switch between instruction buffers 
incurred a penalty of two cycles. Instead of 
using a conventional least recently used 
replacement policy, the Cray-1 selected 
the buffer that had been loaded least recently 
(that is, it used a cyclic replacement poli¬ 
cy) to hold new instructions brought from 
main memory. Like the cache of the 360/ 
85, the buffer filled in a circular manner, 
with the requested item delivered first. 

A cache improves the apparent memory 
cycle time when a hit occurs. The effective 
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Figure 2. The impact of the t M lt c ratio and the hit ratio on performance. 


memory access time t eff of a system with a 
cache can be approximated as: 

t e jf = h ■ tc + (l — h) ■ t M 
To minimize t e g, it is important to 

• maximize the cache hit ratio h, 

• maintain a low t c as dictated by f,, and 

• have a “reasonable” t M so that misses 

are not too costly. 

From the perspective/of the processor, the 
value of t M becomes t c for a cache hit. 

The cache hit ratio can only approach 
the ultimate limit of 100 percent because a 
cache miss must occur before the cache can 
contain any valid information. To improve 
the cache hit ratio, the designer must adjust 
numerous (and frequently interdependent) 
parameters. 3 In addition, other factors such 
as the instruction set, code generation quality 
(that is, compiler effectiveness), and the 
application (program) are beyond the cache 
designer’s control. Each of these factors 
can significantly affect the cache hit ratio. 
Separate invocations of the same program 
with different inputs can even produce dif¬ 
ferent hit ratios for the same cache. 

We normalize the equation for t eff to t c 
and show the influence of h on the ratio of 
t eff / t c for several values of t M / t c in Figure 
2. Because the cost of a cache depends on 
many parameters that must be evaluated on 
a case-by-case basis, Figure 2 does not 
show the cost of achieving a specific level 
of performance. 

By implementing a cache in the same 
technology as that of the processor, the 
designer can decrease cache cycle time at 
the same rate as the processor’s primary 
clock-cycle period. Each new generation 
of processing technology produces faster, 
larger capacity dynamic RAMs than the 
previous generation. Nevertheless, the main 
memory cycle time has been decreasing 
less rapidly than the clock period for pro¬ 
cessors, and continuous improvements in 
the cache hit ratio are required to maintain 
a low t eff value in high-performance sys- 

Although the cache hit ratio is largely 
affected by cache size, increases in this 
size must also be weighed against a longer 
access t c and higher cost. 4 For a given 
memory technology, the cache memory 
cycle period t c increases for larger cache 
sizes due to the additional decode logic and 
loading of the buses (both internal and 
external to the memory chips). When the 
critical path of the processor includes t c , the 
processor’s primary clock period increases 


and any performance advantages resulting 
from a higher cache hit ratio may be negat¬ 
ed. The cost of a cache increases propor¬ 
tionally to its size, and—in absolute terms 
—the hit ratio improves with size (assuming 
other parameters remain equal). The rate at 
which the hit ratio improves, however, 
decreases as the size of the cache increases 
(that is, the law of diminishing returns ap¬ 
plies). In other words, each incremental 
performance improvement becomes more 
expensive. 

During the cache “warm-up period,” the 
hit ratio is low. A cache that cannot warm 
up in the short execution time of some 
programs provides little benefit. On multi¬ 
tasking systems with frequent conte\. 
switches, the performance impact can be 
significant for programs with long execu¬ 
tion times if the cache must be flushed on 
each context switch and a warm-up period 
is required when the process is restarted. 

Larger main memory and higher instruc¬ 
tion-execution rates have enabled the de¬ 
velopment of more complex programs 
(as measured by the static and dynamic 
number of instructions). For example, the 
core image of the X Windows server is 
substantially larger than early versions of 
the entire Unix operating system. Inevita¬ 
bly, further increases in cache size will be 
difficult, and alternate solutions such as 
multilevel caches are becoming necessary 
to achieve high performance. 

The effect of caches in instruction se¬ 
quencing is profound. The entire idea of 
computational kernels of code is based on 
the fact that whatever fits in the cache runs 
fast and near-peak performance can be 
attained for substantial portions of the dy¬ 
namic execution profile. Since the instruc¬ 
tion request and the instruction-execution 
logic can remain unchanged, the use of 
caches allows upward compatibility with 
existing systems. Elimination of the dis¬ 


parity between t M and tj enabled computer 
architects to focus on reducing the value of 
t E ; however, we expect that caches cannot 
provide acceptable revalues indefinitely. 

The impact of RISC 

Due to the significant impact of caches, 
there were few innovations in the area of 
instruction sequencing for nearly a decade. 
The main thrust in computer architecture 
in the seventies was to reduce the semantic 
gap between high-level languages and 
machine language. Complex instructions 
were designed to denote a more substantial 
component of the user’s intended applica¬ 
tion. As a result, a program composed of 
complex instructions performed the same 
task as before but required less memory 
traffic during execution. The program also 
allowed the execution unit to run at peak 
performance more often. The instruction¬ 
sequencing mechanism was not different; 
only the computational effect of the in¬ 
structions varied due to the increased se¬ 
mantic content. In terms of the previously 
expressed parameters, the objective was to 
perform as many useful computations as 
possible for each instruction with little 
concern for the resulting t E value. The goal 
was valid, but the compiler technology 
could not utilize these complex instruc¬ 
tions effectively in the translation of high- 
level language programs. 

In contrast, the goals in reduced instruc¬ 
tion-set computing (RISC) processors were 
to reduce the latency for all aspects of 
instruction sequencing and execution and 
to balance the parameters t M , t E , and Using 
simple instructions with minimal t B values 
achieved this balance. Although more of 
these instructions may be required for the 
execution of a given task, RISC processors 
can achieve higher performance because 
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• their cycle time can be reduced more 
readily as technology advances, and 

• the use of caches prevents t M from be¬ 
coming a bottleneck. 

In addition, compilers performing optimi¬ 
zations can more readily exploit the regu¬ 
larity and simplicity of the instruction 
pipeline. The performance improvement 
that a sophisticated compiler provides was 
recognized by research groups at Stanford 
and IBM during development of their re¬ 
spective RISC processors. A synergistic 
hardware and software methodology cou¬ 
pled with the substantial cost reduction and 
size increase of DRAMs has thrust the 
concepts of RISC into the forefront of 
computer architecture. 

These processors shifted much of the 


complexity associated with instruction se¬ 
quencing from hardware to software. The 
360/91 of the late sixties fetched unneeded 
instructions, initiated instructions that could 
alter the execution state irreversibly, and 
executed instructions out of order. Correct 
operation was achieved by employing so¬ 
phisticated hardware. In contrast, the 
hardware of the MIPS R3000 of the late 
eighties performs few checks on the state 
of computation. Instead, it relies heavily 
on the compiler to eliminate hardware con¬ 
flicts. 

A fundamental principle of the RISC 
philosophy is that performance can be im¬ 
proved by making the processor’s pipeline 
more regular. To accomplish this, the pro¬ 
cessors generally use instructions of uni¬ 
form size to simplify the fetching and de¬ 


coding mechanism. Because the bound¬ 
aries between these instructions can be 
identified without decoding any previous 
instruction, the simpler I-unit can sequence 
instructions more effectively. RISC pro¬ 
cessors are successful largely because their 
designers paid attention to all issues that 
affect computer performance, although 
many of the solutions are not intrinsic to 
reduced instruction sets. For example, the 
use of delayed branches relies solely on 
whether the compiler can find useful in¬ 
structions to place into the delayed branch 
slots (or alternatively place NOP instruc¬ 
tions). 

The use of delayed branches led not only 
to simplified pipeline design but also to 
potentially substantial performance gain at 
no hardware cost. Even though present 


A cache miss here, a jump-broken pipeline there 


Sidney Harris’ cartoon poignantly makes the case for com¬ 
puter performance loss. Indeed, the individual events of com¬ 
puter performance are measured in only thousandths, mil¬ 
lionths, or even billionths of a second. Alternatively, the 
caption of the cartoon could read “...a page fault here, a con¬ 
text switch there ... ,” or even (in the finer grain) “...a cache 
miss here, a jump-broken pipeline there ... .” 

The problem is not that these delays occur — it’s that they 
recur. Even major delays on the order of milliseconds are 
generally tolerable — if they are nonrecurring. For example, 
the duration of a typical Reset signal may be in the range of a 
few hundred microseconds to ten milliseconds. This type of 
signal is associated with a cold or warm start, which occur 
very infrequently. It also relates to infrequent catastrophic 
events such as a system crash or power failure. 

The types of delays that most affect the lives of computer 
architects are the ones with the greatest frequency and asso¬ 
ciated performance penalty. A 16-MHz PC with one wait state 
in its memory is slower than another PC that runs at 12 MHz 
with no wait states. Although the wait-state penalty may be 
only one cycle, it occurs for every memory reference and can 
significantly degrade overall operation. 

A system with a 97 percent cache hit rate (including instruc¬ 
tions and data) and a memory cycle four times slower than 
the cache cycle suffers a 9 percent performance degradation 
from cache misses alone. As the grain of performance loss 
becomes coarser, the degradation of performance per occur¬ 
rence is higher, even though such occurrences are generally 
less frequent. For example, context switches may take a few 
microseconds (the exact time depends on the processor and 
operating system), but they typically occur far less often than 
cache misses. 

A goal of a computer architect is to develop effective de¬ 
signs that satisfy some need at a reasonable cost to the user. 
This fact can complicate the life of a computer architect. Re¬ 
duction of cache misses per se is not necessarily an objective 
of computer design. Reduction of cache misses without a cost 


increase, on the other hand, is a worthwhile goal because it 
leads to better cost performance. 

The large number of parameters involved in computer de¬ 
sign, the ever-changing underlying technology, and ever-in- 
creasing user needs lead to many challenges and opportuni¬ 
ties for innovation. Although ever-present, the sources for 
performance degradation change over time. Nevertheless, we 
think that Sidney Harris’ cartoon will be pertinent well into the 
next century. 
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Figure 3. CRISP hardware for instruction sequencing. 


compilers are very good at filling delayed 
branch slots, no strategy for scheduling 
instructions 5 can guarantee that even the 
first delay slot will always be filled. Con¬ 
sequently, each unfilled delay slot corre¬ 
sponds to degraded processor performance 
during the period that the target of the 
branch instruction is being fetched from 
memory. To reduce performance degrada¬ 
tion associated with unfilled delay slots, 
the stage at whic^ the target address is 
determined must bejpositioned closer to 
the beginning of the pipeline. Replacing 
implicitly set condition codes with Fast 
Compare instructions can allow an earlier 
resolution of the target address. This scheme 
requires dedicated hardware to perform an 
explicit bit-wise comparison rather than 
using the ALU to perform the more com¬ 
plex and time-consuming subtraction op¬ 
eration. 

As we pointed out, the primary emphasis 
of instruction sequencing for RISC proces¬ 
sors switched from hardware to software. 
For high-performance instruction execution, 
these processors characteristically require a 
memory that allows t eff to approach t h which 
is generally accomplished with the use of 
caches. 

Recent innovations 

The past decade has seen renewed inter¬ 
est in instruction sequencing. Designers 
have proposed a variety of hardware and 
software approaches such as branch pre¬ 
diction strategies and instruction-scheduling 
techniques to further improve performance. 

Compilers can improve performance by 
manipulating a program’s instructions pri¬ 
or to execution. To reduce the relative 
frequency of branch instructions, the pro¬ 
grammer can implement techniques such ' 
as loop unrolling and subroutine in-lining. 
Compiler optimization can perform the same 
task. However, these techniques increase 
program size, and they cannot be univer¬ 
sally applied (especially in the case of 
recursive subroutines). Although these 
techniques make the greatest impact when 
used with short loops and small subroutines, 
their benefits do not generally scale with 
program size because they can significant¬ 
ly affect page faults and cache misses. 

Software approaches that reduce the fre¬ 
quency of cache misses 6 have been inves¬ 
tigated recently. After researchers collect¬ 
ed the typical traces of a given program, 
they rearranged the instructions to increase 
the cache-hit ratio for future program in¬ 
vocations. The hit ratio of the cache is 


improved by reducing the conflicts associ¬ 
ated with the placement of instructions in 
memory. Two factors limit the scope of 
these techniques. Typical traces for a pro¬ 
gram must be identified, and the program 
must be executed repeatedly with rear¬ 
ranged instructions to amortize the cost of 
the complex procedure. Although it is not 
sequencing per se, this useful method can 
lead to better performance without hardware 
modifications. 

Branch prediction strategies can also 
reduce the performance degradation asso¬ 
ciated with sequencing instructions in the 
presence of branch instructions. This 
technique predicts the target of a branch 
instruction and begins fetching instruc¬ 
tions at this address. Although these in¬ 
structions can begin execution, none of the 
instructions can be allowed to alter the 
state of the processor irreversibly. An in¬ 
correct guess about the target requires that 
all instructions be flushed from the pipeline. 

Branch prediction strategies are either 
static (as when a compiler detects a loop) 
or dynamic (as when the program flow 
follows the direction previously taken by a 
branch). Researchers have developed and 
characterized both types of branch predic¬ 
tions. 7 

Achieving high performance with any 
branch prediction strategy-requires high 
accuracy in predicting the direction of the 
conditional branch instruction. The perfor¬ 
mance degradation for a branch prediction 
strategy is a function of the frequency of 
branch instructions, the frequency of wrong 
guesses, and the penalty associated with 
making an incorrect prediction. Although 
it is clearly impossible for any strategy to 
predict with 100 percent accuracy, the rate 
of correct predictions differs for each pro¬ 
gram executed. 

One technique for dynamic branch pre¬ 
diction uses a dedicated cache, or branch 
target buffer, to store the instructions from 
the targets of previously executed branch 
instructions. 7 By assuming that the target 
of each branch instruction nearly always 


matches its most recently taken target, the 
processor can fetch the instruction from 
the branch target buffer as soon as the 
instruction is identified. As in other pre¬ 
diction schemes, incorrectly guessing the 
target of the branch incurs a penalty to 
allow retrieval of the instruction for the 
correct target from memory. If the branch 
target buffer does not contain the target, 
the instruction must be executed to deter¬ 
mine the target so that the proper instruc¬ 
tion can be retrieved from the memory 
hierarchy. The frequency of this latter sit¬ 
uation is reduced by adjusting the branch 
target buffer parameters in a manner anal¬ 
ogous to decreasing the miss ratio of a 
cache. The Advanced Micro Devices 29000 
microprocessor has incorporated a branch 
target buffer (called a Branch Target Cache) 
on chip. 

The AT&T CRISP microprocessor in¬ 
corporated a variety of techniques to reduce 
the performance degradation associated 
with instruction sequencing. 8 As shown in 
Figure 3, the CRISP processor contains a 
512-byte prefetch buffer (actually a direct- 
mapped instruction cache with 32 lines), a 
prefetch and decode unit, a decoded in¬ 
struction cache, and an E-unit. Operating 
independently of the E-unit, the prefetch 
and decode unit fetches and decodes in¬ 
structions from the prefetch buffer and 
stores them in the decoded instruction cache 
for the E-unit to read. 

Using a technique called branch folding, 
the prefetch and decode unit combines a 
branch instruction with the previous in¬ 
struction, which often eliminates the exe¬ 
cution time of the branch instruction. This 
technique uses a Next Address field in the 
decoded instruction cache to specify the 
address of the next instruction. All uncon¬ 
ditional branch instructions that have stat¬ 
ically defined targets can thus be eliminat¬ 
ed. However, the processor needs additional 
support to fold conditional branch instruc¬ 
tions with statically defined targets. Static 
branch prediction is used to set a single bit 
in each conditional branch instruction to 
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indicate whether the branch is predicted to 
be taken. The address of the predicted 
target fills the Next Address field, and an 
Alternate Address field in the decoded in¬ 
struction cache stores the address of the 
target that is predicted not to be taken. 

If the condition codes are valid upon 
initiating the instruction with which the 
conditional branch has been folded, the 
branch target can be determined (the exe¬ 
cution time of the conditional branch in¬ 
struction is zero). Otherwise, subsequent 
instructions from the predicted branch target 
begin to be executed. These instructions 
must be flushed from the pipeline when the 
branch target is incorrectly predicted. The 
alternate address must be used to fetch the 
correct instructions. CRISP uses branch 
spreading to increase the likelihood that 
the condition codes will be valid in these 
circumstances. 

Although CRISP contains a combination 
of techniques to improve the performance 
associated with instruction sequencing, the 
following situations degrade performance: 

• The next instruction for execution is 
not in the prefetch buffer. 

• The instruction specified by the Next 
or Alternate Address field is not in the 
decoded instruction cache. 

• The condition codes are not valid early 
enough for execution of the instruction 
with which the conditional branch in¬ 
struction is folded, and the predicted branch 
is not taken. 

• The target of the branch instruction is 
determined dynamically. 

Decreasing the impact of the first two 
situations reduces to the problem of im¬ 
proving cache performance. The last two 
situations are the bane of all advanced 
instruction-sequencing techniques. 

Although interinstruction dependencies 
ultimately limit the rate at which instruc¬ 
tions can be executed, independent in¬ 
structions can be executed simultaneously 
with appropriate hardware support. This 
increased level of concurrency within the 
processor results in higher rates of instruc¬ 
tion execution without an increase in the 
performance of the underlying circuit 
technology. Over the last two decades, 
many researchers have evaluated the fine- 
grain (instruction-level) parallelism in¬ 
herent in sequential programs. 9 They have 
proposed a variety of methods to initiate 
multiple instructions within the single cy¬ 
cle period of a conventional machine. 

With appropriate hardware resources, 
Tomasulo’s algorithm for dispatching in¬ 


structions in the 360/91 can be enhanced to 
initiate the execution of multiple instruc¬ 
tions (possibly out of order) within a single 
cycle. Sophisticated hardware such as 
reservation stations shifts the bottleneck 
within the processor from the updating of 
registers to the availability and latency of 
the functional units as in the HPS and 
similar architectures. 10 Only a detailed 
evaluation of existing systems will resolve 
whether the overhead for the complex 
hardware in dynamic pipelines is warrant¬ 
ed for higher performance. The same holds 
true for whether the associated main mem¬ 
ory design can overcome the bottlenecks 
seen in earlier systems of this type, such as 
the 360/91. 

Another approach to increase concur¬ 
rency uses very long instruction words 
(VLIWs) to control the synchronous exe¬ 
cution of multiple processors. Prior to 
program execution on a VLIW architecture, 
a single instruction stream consisting of 
concatenated instructions for each processor 
must be produced. Data availability largely 
affects this process, known as trace 
scheduling. Trace scheduling is appropri¬ 
ate for programs that also are suitable for 
vectorization. 11 As a result, it is unclear 
whether VLIW hardware is more cost-ef¬ 
fective than vector machines for these ap¬ 
plications. Nonetheless, commercial sys¬ 
tems using this method have shown good 
performance. Variants of VLIW methods, 
such as the ROPE architecture, use program- 
flow analysis to statically schedule in¬ 
struction prefetch. Further study in this 
area is also warranted. 

Using hardware to identify independent 
instructions that can be executed in parallel, 
the superscalar approach can simulta¬ 
neously dispatch multiple instructions for 
execution. Superscalar implementations 
such as the Intel 80960CA and the IBM 
RS/6000 12 feature heterogeneous functional 
units that can be used simultaneously. Initial 
results from this work are very promising, 
and the commercial implementation and 
availability of these processors demonstrate 
a maturing technology. One issue yet to be 
resolved is whether the main memory or¬ 
ganization of such processors can follow 
conventional designs, or whether the in¬ 
creased traffic requires drastic changes. 

Although the techniques described in 
this section reduce performance degrada¬ 
tion due to control dependencies, many 
architectures also use methods to increase 
the level of concurrency within a processor 
by addressing the interinstruction data 
dependencies. Even in the absence of data 
dependencies, the presence of conditional 


branch instructions can be a severe obsta¬ 
cle to obtaining high performance. 13 Con¬ 
sequently, addressing both control and data 
dependencies simultaneously has not sig¬ 
nificantly altered the relative degradation 
associated with branch instructions. More¬ 
over, we expect the performance degrada¬ 
tion due to remaining control dependencies 
to increase as early identification of branch 
targets becomes more difficult. 

Future methods 

Based on the available technology and 
cost trade-offs, each period of computer 
design is characterized by different ap¬ 
proaches to instruction sequencing. It is 
appropriate, as a new decade begins, to 
evaluate the options and constraints that 
designers face. The present trend in com¬ 
puter design tends toward orthogonal in¬ 
struction sets, single-cycle execution for 
most instructions, effective use of regular 
pipeline designs, and heavy dependence 
on compiler optimization. Instruction 
scheduling is now primarily a compiler 
task, even for emerging superscalar designs 
that can execute more than one instruction 
per cycle. 

Based on existing technology, the 
approaches to increasing uniprocessor 
performance are relatively few: larger 
caches, cache hierarchies, improved 
branch-prediction techniques, and better 
compiler technology. Despite the head 
start of RISC, alternatives that better 
use the aggregate memory bandwidth 
may become feasible. 

As previously described, the memory 
design for a large aggregate bandwidth is 
actually quite easy, but selective commu¬ 
nication of the required instructions to the 
processor is much more difficult. We be¬ 
lieve that future instruction-sequencing 
designs should feature proactive rather than 
reactive memory. In the producer-consumer 
model, the memory should produce the 
correct instruction before the execution 
unit needs it, thus eliminating the depen¬ 
dence of t/ on t M and t E for branch instruc- 

Because the possible targets for a branch 
instruction are statically defined in nearly 
all cases, a program-flow graph, extracted 
prior to execution, contains nearly all in¬ 
formation necessary to sequence instruc¬ 
tions. When multiple paths exist from the 
memory to the processor, the program- 
flow graph can be used during program 
execution to initiate the prefetch of all 
instruction sequences identified as possi- 
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ble candidates for impending execution. 
Because one memory bank cannot prefetch 
independent instructions simultaneously, 
the compiler must rearrange program in¬ 
structions to ensure that the code for the 
branch-taken and branch-not-taken cases 
resides in different memory banks. 

With this combination of hardware and 
software, the processor can run at peak 
performance frorfi “slow” main memory 
for the duration of large programs. Fur¬ 
thermore, interrupt response and context 
switches do not require cache warm-up 
time. After the first few references (less 
than 10), prefetching is accomplished de¬ 
terministically and with known perfor¬ 
mance. This type of organization (which is 
independent of the instruction set or pipe¬ 
line design) is called a Sustained Perfor¬ 
mance Architecture. A working prototype 
of a SPA-type computer has been con¬ 
structed at Duke University, and we are 
investigating the issues related to high- 
performance operation. Reference 14 pro¬ 
vides an overview of SPA and the motivation 
for it. Several theses and technical reports 
contain the theorems and details of opera¬ 
tion, and publication of the SPA theory is 
forthcoming. 

In the area of instruction sequencing, a 
significant amount of information known 
prior to execution remains to be exploited. 
An incremental increase in hardware and 
software complexity together with this in¬ 
formation can help improve performance. 
Computer architects in search of higher 
performance must remain alert for alterna¬ 
tive techniques and organizations that be¬ 
come attractive as changes in technology 
occur. 


I nstruction sequencing has been a key 
aspect in computer architecture for 
several decades. Although today’s 
computer designer can choose from a wide 
variety of organizations, the interaction 
between memory and processor remains a 
focal point in the design of high-perfor¬ 
mance systems. The evolution of instruc¬ 
tion sequencing has come full circle, and 
t M is the same major bottleneck in the 
nineties that it was in the fifties. We be¬ 
lieve that the general-purpose computer 
architecture of the next decade will evolve 
to feature a proactive memory organiza¬ 
tion to supply instructions to the execution 
unit to bridge the increasing gap between 
memory and processor speed. ■ 
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Autonomous Robotic 
Inspection and Manipulation 
Using Multisensor Feedback 


Mongi A. Abidi, Richard O. Eason, and Rafael C. Gonzalez 
University of Tennessee, Knoxville 


R obots have become a major ele¬ 
ment in today’s industrial world. 
They are beneficial not only for 
tasks at which they are more efficient than 
humans, but also for undesirable tasks that 
are strenuous, boring, difficult, or hazard¬ 
ous — not to mention more expensive or 
impossible for humans to perform. Robotic 
systems are used in hazardous environ¬ 
ments such as those encountered in nuclear, 
military, chemical, underwater, and space 
applications. In such environments, auton¬ 
omous operations should be the norm. Total 
or partial autonomy will enhance safety, 
reliability, productivity, and adaptability, 
and will eventually reduce the overall cost 
of most robotics applications. 12 

To achieve autonomous systems, the hu¬ 
man presence or telepresence should be 
replaced, to some degree, by an array of 
sensors capable of mapping the environ¬ 
ment in which they operate. Sensory feed¬ 
back is of great importance in many intel¬ 
ligent robotic applications requiring 
recognition and handling of complex 
workpieces. The sensory system should be 
able to acquire, fuse, and interpret multi- 
sensory data in order to generate action 
items commensurate with a given task. The 


At the core of a 
robotic system is its 
capability to acquire, 
fuse, and interpret 
multisensory data, 
such as vision, range, 
and touch, to generate 
appropriate actions to 
perform a given task. 


need for several sensors is evident from the 
complexity of the inspection and manipu¬ 
lation tasks required in industrial applica- 

Sensors that perform inspection and ma¬ 
nipulation tasks in a variably structured or 
unstructured workspace are often used ac¬ 
cording to the following three steps: 

0018-9162/91/0400-0017S01.00 © 1991 


(1) On the basis of collected sensory 
data, a model of the workspace is built and 
continuously updated. Knowledge in this 
model relates to the position, orientation, 
size, and other features of objects in the 
workspace. 

(2) Using the model built in step 1, along 
with a list of tasks to be performed, the 
system establishes a list of feasible tasks 
and generates motion primitives and sens¬ 
ing assignments to implement them. 

(3) After planning and verification, the 
system performs each of the tasks selected 
in step 2. 

The robotic system described in this ar¬ 
ticle is a six-degree-of-freedom industrial 
robot to which we added a number of sen¬ 
sors — vision, range, sound, proximity, 
force/torque, and touch — to enhance its 
inspection and manipulation capabilities. 

The work described falls under the scope 
of partial autonomy. In teleoperation mode, 
the human operator prepares the robotic 
system to perform the desired task. Using 
its sensory cues, the system maps the 
workspace and performs its operations in a 
fully autonomous mode. Finally, the sys¬ 
tem reports back to the human operator on 
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Figure 1. Experimental setup showing the robot and task panel used for the valve 
manipulation experiment. 



Figure 2. The instrumented end-effector and its sensors used for inspection 
and manipulation experiments: (1) vision, (2) range and sound, (3) proximity, 
(4) force/torque, and (5) touch. 


the success or failure of the task and re¬ 
sumes its teleoperation mode. Several 
multisensor robotic systems addressing 
similarissues have been implemented. They 
include the Autonomous Land Vehicle 
Project, 3 the Nav Lab Project, 4 and other 
systems, some of which were the subject of 
two 1989 special issues of Computer: Ro¬ 
botics and Automation 5 and Autonomous 
Intelligent Machines. 6 

As noted by many researchers in this 
field, the design, implementation, and test¬ 
ing of “large” robotic systems is a complex 
task because it often involves disciplines 
that no single researcher or research team 
can fully master. One added dimension to 
this problem, aside from figuring out the 
details of developing, identifying, or test¬ 
ing the right edge detector or pose estima¬ 
tion algorithm, is that of system engineer¬ 
ing and integration. Integrating various 
methods and their implementations in real- 
world problems is sometimes far more 
challenging than developing each method 
alone. 

Objective: Automation 
through multisensing 

The intent here is to demonstrate the 
feasibility of realistic autonomous robotic 
inspection and manipulation tasks using 
multisensory information cues (Figures 1 
and 2). The goal is to clearly emulate the 
operation of a control panel in a nuclear 
power plant. To achieve this goal, a testbed 
was designed, fabricated, and tested. It 
includes indicators and controls such as 
analog and LCD meters, valves, sliders, 
switches, push buttons, emergency knobs, 
and audible alarms. This task panel is used 


Table 1. Examples of sensing tasks, sensor selection, and sensor design criteria. 


Sensing Tasks (Example) 

Sensor 

Design Criteria 

Pose estimation, object recogniton 

Vision 

Sensor resolution, target size, 

spatial/spectral/relational properties, processing speed 

Depth estimation (pose refinement) 

Range 

Spatial resolution (cone size), depth accuracy 

Alarm detection 

Sound 

Response time, sensitivity (noise) 

Presence/absence of objects, near-field 
inspection (before manipulation) 

Proximity 

Sensitivity, sensing volume, surface characteristic^ 

Mating/demating of 
interchangeable end-effector 

Force/torque 

Sensitivity, maximum load, response time, data processing 

Presence/absence of objects 
(during manipulation) 

Touch 

Response time, ruggedness, resolution (array) 
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Figure 3. World coordinate system (X, Y, Z) with respect to the robot. Arbitrary 
relative task panel coordinate system ( X p , Y p , Z p ) with repect to the world coordi¬ 
nate system. 


extensively to (est various sensing algo¬ 
rithms developed for the Department of 
Energy University Program in Robotics 
for Advanced Reactors. 7 

Sensing tasks. The system is pro¬ 
grammed to perform several inspection 
and manipulation tasks including (1) read¬ 
ing digital commands, (2) using light tar¬ 
gets for pose estimation, (3) identifying a 
meter and reading its status (analog and 
digital), (4) recognizing and manipulating 
a valve (either directly or with a tool), (5) 
setting a slider control, (6) opening and 
closing a tool rack, (7) turning various 
switches on and off, (8) operating an emer¬ 
gency knob, and (9) detecting an alarm. 
Each of these tasks is implemented as an 
independent module that can be combined 
with others to form more complex experi¬ 
ments. 

Table 1 gives some examples of the 
rationale used in designing the robotic sys¬ 
tem and its sensors. It lists sensing tasks, 
the sensors selected to perform those tasks, 
and the design criteria that led to a given 
choice. 

System constraints. The environment 
is variably structured. Only the relative 
position of the manipulator or end-effector 
with respect to the workpieces being ma¬ 
nipulated is unknown when data is being 
sensed. This does not preclude relative 
motion of objects once an experiment is 
initiated. A task is performed using infor¬ 
mation from vision, range, sound, proxim¬ 
ity, force/torque, and touch sensing. The 
robot relies on information stored in its 
knowledge base and new information col¬ 
lected by the robot sensors. Operations are 
fully autonomous; that is, the sequence of 
events and the robot moves are not prepro¬ 
grammed, nor does the operator intervene 
in interpreting sensory data on behalf of 
the robot. Robot operations are performed 
in either (1) a fixed coordinate system 
attached to the base of the robot or (2) a 
relative coordinate system attached to the 
task panel. The task panel can be in any 
arbitrary position in the fixed coordinate 
system (Figure 3). 

The paradigm we followed to build the 
task panel can be summarized as follows: 

• The relative position of the robot with 
respect to the task panel is arbitrary be¬ 
cause in the real world the robot is mobile 
and the panel may be moved unexpectedly. 

• Tools and controls mounted on the 
task panel are rigidly fixed with respect to 
the panel; hence, only their relative two- 


dimensional positions are unknown with 
respect to the panel coordinate system. 

• Tools used by the robot are rigidly 
fixed relative to the base of the robot; 
hence, their three-dimensional pose is 
known relative to the fixed coordinate sys- 

• Once the system determines the posi¬ 
tion of a tool/control, its status needs to be 
determined. 

The above paradigm determines what 
information is stored in the system knowl¬ 
edge base prior to beginning an experiment 
and what needs to be determined during the 
experiment so that operations are fully 
autonomous and hence require no human 
intervention. 

System architecture. The cooperative 
use of multisensory information for auton¬ 
omous operations is performed using 

• a Cincinnati Milacron T 3 -726 six-de- 
gree-of-freedom industrial robot; 

• added sensors including vision, range, 
sound, proximity, force/torque, and 
touch; 

• a Perceptics-9200E image processor; 
and 

• a VAX 11/785 computer running VMS. 

Functionally, the system can be divided 
into fourmodules: control, sensing, intelli¬ 
gence, and action (Figure 4). The robot 
system control (RSC) module is a collec¬ 
tion of programs, one for each experiment. 
A program is a sequence of “procedure 


calls” invoking the three other modules in 
the proper order to execute the task. 

The sensing module is a collection of 
functions that can be initiated or terminat¬ 
ed by the RSC module. Each function per¬ 
forms a set of processing operations on 
data gathered by the six sensors. Other 
sensors are presently being added to this 
module. 

The intelligence module is a collection 
of functions that examine the appropriate 
sensory data and the system knowledge 
base to determine proper action. Reason¬ 
ing occurs on the basis of scene informa¬ 
tion, robot parameters, and sensor status. 

The action module is a collection of 
functions that control and report the status 
of the end-effector and sensors. Data ac¬ 
quired by the sensors are formatted and 
transferred through this module to reside in 
their appropriate sensing submodule. 

The control, sensing, intelligence, and 
action modules are embedded in a knowl¬ 
edge base system accessible to all submod¬ 
ules. This knowledge base embodies infor¬ 
mation relevant to the system constraints 
described above. 

All functions implementing these mod¬ 
ules are written in Fortran or C. As shown 
in Figure 4, no direct communication is 
allowed between the 12 submodules. The 
status of the robotic system software mod¬ 
ules as well as that of each hardware com¬ 
ponent is fully controllable and observable 
by the RSC. Since the robotic system is 
modular (hardware and software), it can 
perform a variety of task scenarios on the 
simulated task panel built for this purpose. 
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Figure 4. Interface functions for autonomous robotic inspection and manipula¬ 
tion. 


The VAX-based system described here 
is only a laboratory testbed. After testing, 
each of the submodules is ported to a mul¬ 
ticomputer heterogeneous system. That 
system includes a parallel N-Cube hyper¬ 
cube system, Silicon Graphics worksta¬ 
tion, and a MicroVAX to integrate experi¬ 
ments, similar to the one profiled in this 
article, into a large demonstration of mul¬ 
tisensor robotic inspection and manipula¬ 
tion for nuclear maintenance and repair 
functions. 7 

Valve experiment. Valve operation 
typifies inspection and manipulation tasks 
in nuclear environments. To illustrate the 
cooperative use of sensors in performing 
autonomous operations, we’ve selected an 
experiment that has the robot locate, in¬ 
spect, and adjust a valve on the control 
panel to a given position without exceed¬ 
ing a preset threshold. In the experiment 
the valve final reading is arbitrarily set to 9 
on a scale of 0 to 10, and the threshold is 
arbitrarily set to 7 to simulate an operator 
error. The initial reading of the meter is 
below this threshold. This simulates an 
undesirable drop in the volume or pressure 
controlled by this valve, the reading of 


which should not exceed 70 percent of its 
total scale. The valve position is indicated 
by both analog and digital meters. The 
experiment also involves the detection and 
acknowledgment of a sound alarm by op¬ 
erating an emergency knob. 

This article focuses specifically on the 
estimation of the three-dimensional posi¬ 
tion and orientation of the task panel and 
the use of other non vision sensors for valve 
manipulation. The two-dimensional aspects 
of this experiment, which deal primarily 
with image processing and interpretation, 8 
are not covered here. The system has also 
been used to perform a series of inspection 
and manipulation operations of interest to 
space robotics. 1 

Vision aspects 

Vision sensing refers to the two-dimen¬ 
sional optical information provided by a 
vision sensor or camera. There are virtual¬ 
ly no vision sensors built specifically for 
robotic applications. Most are borrowed 
from the television industry. They are the 
wrong size and are not rugged or sensitive 
enough. Vidicons and solid-state arrays 


are two types of cameras commonly 
mounted on a robot for vision sensing. 
Both are available in resolutions ranging 
from approximately 32 x 32 to 512 x 512 
sensing elements per picture. In general, 
these cameras are rigidly fixed to the ma¬ 
nipulator to simplify the coordinate trans¬ 
formation between the world system and 
the camera system. Because solid-state 
cameras are smaller and more rugged, they 
are more widely used. However, vidicons 
are generally cheaper and present fewer 
interfacing problems with image process¬ 
ing systems, so they may be preferred for 
fixed mounting in the workspace. 910 

Of all the sensing modalities, vision has 
the widest potential range of applications. 
Vision sensors can be used as a substitute 
for or in conjunction with many other sen¬ 
sors for object detection, recognition, loca¬ 
tion, and inspection. Such tasks can be 
performed before contact, thus allowing 
the robot to plan its actions before move¬ 
ment. This contrasts with other sensors 
that may require extensive robot motion to 
accomplish the tasks. Because visual im¬ 
age processing involves large amounts of 
data, it requires algorithms of far greater 
complexity than those for other sensors, 
and a number of contributing factors 
compound the situation. For example, the 
loss of information in the projection process 
makes it difficult to deduce three-dimen¬ 
sional locations from a two-dimensional 
image. If the object’s movement is restricted 
to a plane such as a table or conveyor belt, 
deducing the location may be fairly sim¬ 
ple. However, if motion is unrestricted, 
deducing a three-dimensional location may 
be much more difficult, and it may require 
structured lighting, stereo vision, camera 
calibration, and other multiple imaging 
techniques. 

Lighting conditions in the workspace 
also place a significant burden on image 
processing algorithms. Among these con¬ 
ditions are inadequate or nonuniform light, 
shadows, reflectance variations, and oc¬ 
clusion of objects. The latter problem may 
result from atmospheric occlusions such as 
smoke, from other objects (as in picking a 
part from a bin), or from the robot hand 
itself if the camera cannot be positioned on 
the end-effector. Although many tasks re¬ 
quired of intelligent robots can be per¬ 
formed with vision sensing, complexity 
and high cost limit its use. 9 

Locating the task panel. This section 
describes a method that determines the 
three-dimensional position and orientation 
of a four-light guiding target used to locate 
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the task panel. We would like to recover 
the three-dimensional position of each of 
the target points, P 0 , P„ P 2 , and P 3 , know¬ 
ing their respective images p 0 , p ,, p 2 , and p 3 
and their relative positions with respect to 
each other (P, = (Y„ Y„ Z,) and p, = (*„ y,)). 

Accurate, fast, and efficient positioning 
of a robot relative to a given target has been 
addressed by using painted lines, infrared 
beacons, and other standard marks as well 
as more complex three-dimensional vision 
techniques. A digest of these methods can 
be found in Tsai" and Yuan. 12 The relative 
position of the robot arm can be deter¬ 
mined to a desired accuracy using a four- 
point light target. The solution is obtained 
by direct computation. This method has 
been investigated, implemented, and test¬ 
ed using a real setup. Here, we discuss the 
necessary mathematical tools. 

In an augmented coordinate system, the 
image coordinates (x,y) of an image point 
are related to the world ( X,Y,Z) by 



y = c J c kA 

where c M , c h2 > c h3 , and c hi represent the el¬ 
ements of the homogeneous coordinates. 
In this discussion, we use the pinhole cam¬ 
era model for our vision sensor. In our 
implementation, however, the sensor-to- 
image transformation, which is affine un¬ 
der the pinhole assumption, is approximat¬ 
ed by a cubic polynomial to account for 
lens abberations. 

In a direct coordinate system having its 
origin at the lens center and its Z-axis 
pointing towards the scene, the image co¬ 
ordinates (x,y) and the world coordinates 
(X,Y,Z) are related as follows: 


W c = AW 


where 

W= (Y,F,Z,l) r 
W _ (X C ,Y C ,Z C ,1) T 


'a, a 2 a 3 a l0 


around the Y-axis with a parameter a. This 
can be expressed as follows: 


0 0 0 1 

The intermediate parameters X C ,Y C , and 
Z c represent the position in the camera 
coordinate system; the elements a, through 
a )2 represent the matrix transformation A 
from world coordinates to camera coordi¬ 
nates. The parameter X represents the focal 
length of the camera. By the very nature of 
the problem, the parameters a, through a 9 
characterize the effect of rotation only, 
whereas a l0 , a n , and a ]2 characterize the 
effect of translation. The objective is to 
compute the elements of the matrix trans¬ 
formation, a, through a n , using the image 
of the target points as well as their three- 
dimensional relative position in order to 
determine the exact three-dimensional po¬ 
sition of those targets with respect to a 
coordinate system relative to the camera. 
Each point provides a pair of linear equa¬ 
tions involving the unknown parameters a, 
through a 12 ; therefore, using these equa¬ 
tions alone, a minimum of six points is 
required to uniquely define the matrix A. 
However, we have shown 1 that by using the 
properties of the matrix A we can reduce 
this number to four. In Abidi and Gonza¬ 
lez, 1 a multiple solution was found using 
three points. A fourth point was added to 
disambiguate the pose problem. In this 
article, a simpler, direct, and unique solu¬ 
tion is formulated using the four points 
simultaneously. 

The matrix A describes the motion(s) that 
a point (X, Y,Z, 1) has to undergo to map into 
( X c , Y C ,Z C , 1). When the translation vector is 
null, the coefficients a 10 , a,,, and a n are zero, 
and a, through a 9 are functions of the rota¬ 
tional movement only. For a three-degree- 
of-freedom movement, the system can be 
described by a rotation around the Z-axis 
with a parameter 0, a rotation around the Y- 
axis with a parameter P, and a rotation 


" cos 6 sin 6 0 0 

-sin0 cos0 0 0 

0 1 0 

0 0 1 

0 -sin/J 0 

1 0 0 

0 cosp 0 

0 0 1 

0 0 0 ' 

os a sin a 0 

““ 0 -sina cosa 0 

0 0 0 1 

Rr= R a RpR e 

The transformation, R T , denotes the total 
movement. The previous equations state 
that this transformation preserves distance. 
Hence, for R T , 



'a, a 2 a, 0 



0 0 0 1 


Each column or row vector in this matrix is 
unitary. Each pair of vectors is mutually 
orthogonal. 

In this approach, we introduce two inter¬ 
mediate coordinate systems, the a-system 
and the P-system, and write A as A = IFS, 
where S is a matrix representing the trans¬ 
formation between the world coordinate 
system and the a-system, F is a matrix 
representing the transformation between 
the a-system and the p-system, and / is a 
matrix representing the transformation be¬ 
tween the P-system and the camera coor¬ 
dinate system (Figure 5). 



Figure 5. Decomposition of the transformation between the world coordinate sys¬ 
tem and the camera coordinate system. 
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Moving the target into standard position 


We find the matrix S, which carries the world coordinate 
system to the a coordinate system, by decomposing it into 
the following sequence of motions: Translate so that P 0 is at 
the origin, rotate about the new Z-axis by an angle 0 so that 
the V-coordinate of P, is zero and the X-coordinate is posi¬ 
tive, rotate about the new V-axis by an angle p so that the Z- 
coordinate of P, is zero, and finally, rotate about the new X- 
axis by an angle a so that the Z-coordinate of P 2 is zero and 
the V-coordinate is positive. If X„, Y 0 , and Z 0 are the coordi¬ 
nates of P„ in the world system, then these transformations 
are described by the matrices 



0 -X 0 
0 ~Y 0 

1 -z 0 
0 1 


0 

0 

0 


5 22 = cos a cos 0 + sin a sin p sin 0 

5 32 = -sin a cos 0 + cos a sin p sin 0 

5 13 = -sin p 

5 23 = sin a cos P 

5 33 = cos a cos p 

5 14 = -X 0 cos p cos 0 - y 0 cos p sin 0 + Z„ sin p 

5 24 = -X 0 (-cos a sin 0 + sin a sin p cos 0) - 

y 0 (cos a cos 0 + sin a sin p sin 0) - Z„(sin a cos P) 

5 34 = -X 0 (sin a sin 0 + cos a sin p cos 0) - 

y 0 (-sin a cos 0 + cos a sin p sin 0) - Z 0 (cos a cos P) 
S 4 , = S i2 = S 43 = 0 
S 44 = 1 


According to the above requirements, we can determine 0 by 
transforming P, using the transformation R e T 0 and setting the 
resulting Y component to zero. Solving the resulting equation 
for ©yields 





cos/J 

0 -sin/J 

0 

1 0 

sin p 

0 cos p 


where S = R a R p R e T 0 . This yields the following for the ele¬ 
ments of S: 


If X, < X 0 , we add ;rto 0 to assure that P, has a positive Xcom¬ 
ponent. Also, if X, = X 0 and y, = Y 0: we arbitrarily set 0 to zero. 
Similarly, we can determine p by transforming P, using the 
transformation R p R e T 0 and setting the resulting Zcomponent to 
zero. Solving the resulting equation for p yields 


^ tan {(X 1 -X o )cos0 + (y,-y o )sin0} 

The angle a is now determined by transforming P 2 using the 
transformation R a P (J P e T 0 and setting the resulting Zcomponent 
to zero. This equation for a yields 


S 14 = cos p cos 0 

S 21 = -cos a sin 0 + sin a sin p cos 0 
S 31 = sin a sin 0 + cos a sin p cos 0 
S 12 = cos p sin 0 


[(X 2 - X 0 ) cos 0 + (y 2 - y„) sin 0] sin p + (Z 2 - Z„) cos ft 
{ -(X 2 -X o )sin0 + (y 2 -y o )cos0 j 


We add n to a if the denominator is less than zero, so P 2 will 
be in the first or second quadrant of the X-Y plane. 


We choose the a-system so that the tar¬ 
get points in this system are in standard 
position whereby P 0 is at the origin, P, is on 
the positive X-axis, and P 2 is in the first or 
second quadrant of the X-Y plane. We as¬ 
sume the four points are coplanar, so P, 
will also be in the X-Y plane. The (3-system 
is chosen to be aligned with a fictitious 
camera that has its lens center (origin) at 
the same location as the real camera but 
oriented such that p a is at the image origin 


and Pi is on the positive x-axis. We say that 
this fictitious camera is in the ideal posi¬ 
tion. 

Both S and I are easily determined from 
the problem data, S from the world coordi¬ 
nates of the target points, and I from the 
image coordinates of their projections. The 
matrix F represents the solution to a some¬ 
what simpler camera calibration problem 
in which target points in standard position 
are viewed by a camera in ideal position. 


This sets many of the coefficients to zero 
and leads to a closed-form solution to the 
problem. Once S, /, and F are found. A, which 
is the general solution to the camera cali¬ 
bration problem, is determined by a simple 
matrix product. The steps for determining 
S, I, and F are given in the three sidebars 
that follow. 

Other vision functions. Besides its use 
in the task panel pose estimation, the vision 
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Moving the camera into ideal position 


The method used in solving for / is similar to the one used 
in solving for S. Here, we can decompose the inverse of / 
(from the camera system to the ^-system) by using the follow¬ 
ing intermediate transformations: Pan the camera system 
about its V-axis by angle 0 until p 0 is on the image y-axis, tilt 
about the new X-axis by angle co until p 0 is at the image origin, 
and finally, rotate about the new Z-axis by angle p until p, is 
on the positive image x-axis. Because the origin (that is, the 
lens center) of the fictitious camera remains at the origin of 
the real camera, each rotation will have a computable effect 
on the image. These transformations are described by the 
matrices 


/ 32 = sin p sin p + cos 0 sin co cos p 
/ 13 = sin 0 cos co 
4 3 = -sin co 
l 3 3 = cos 0 cos co 

/ m =/ 24 =/ 34 = 0 
/ 4t = / 42 = / 43 = 0 


0 -sin0 0 
1 0 0 

0 cos 0 0 

0 0 1 



0 

cos co 


0 


0 


0 


0 

0 

0 


cos p sin p 0 

-sinp cos p 0 

0 0 1 

0 0 0 


We can determine the required angles as we did in solving 
for S, but we must know how the image of a point will change 
following camera rotation about the lens center. For image 
point (x,y), camera focal length A, and camera rotation de¬ 
scribed by the matrix R, we first transform the three-dimen¬ 
sional coordinates of the image point,(x, y,~X) T using the 
transformation R, calling the result (X', Y r , Z 1 ). Then by using 
the projective equation, we find that this three-dimensional 
point (as well as the originating target point) has its image at 
(-X X'/Z', -XY'lZ 1 ) as seen by this rotated camera. 

By transforming the image coordinates of P 0 in this way us¬ 
ing the transformation and setting the x-coordinate of the 
result to zero, we can solve the resulting equation for 0, 
which yields 

0 = tarr’(-XiA) 


where /■' = R p R a R r Because the inverse of a rotation matrix is 
equal to its transpose, we can write / = RJRJR/, which gives 
the following for the elements of I: 

l„ = cos 0 cos p + sin 0 sin co sin p 

4, = cos co sin p 

4, = -sin 0 cos p + cos 0 sin co sin p 
1,2 = -cos 0 sin p + sin 0 sin co cos p 


We solve for co by transforming the image coordinates of P 0 
using the transformation R a R^ and setting the y-coordinate of 
the result to zero. Solving the resulting equation for co yields 

co = tan~'(y 0 cos 0/A) 

Finally, we transform the image coordinates of P, using the 
transformation R P R„,R 0 , set the x-coordinate of the result to 
zero, and solve the resulting equation for p, which yields 
_ [ y, cos w + x, sin 0 sin co - A cos 0 sin co } 

x 1 cos0 +A sin0 


system follows a model-based approach to 
perform other functions such as (1) extrac¬ 
tion of spatial, spectral, and relational fea¬ 
tures from image data and (2) detection, 
recognition, and status estimation of ob¬ 
jects through matching. The knowledge 
base of the vision module contains infor¬ 
mation about general properties of objects 
expected to appear in the scene. They in¬ 
clude shape, minimum/maximum size, and 
intensity relative to neighboring objects. 8 


Nonvision sensing 

Other sensors such as range, sound, 
proximity, force/torque, and touch play a 
significant role in providing the proper 
information for successful completion of 
autonomous valve manipulation. 

Range and sound sensing. Range sen¬ 
sors measure the distance from an object to 


the sensor. Such devices usually operate 
by transmitting an ultrasonic or optical 
beam (such as a laser) and then detecting 
the reflected signal. Time-of-flight sys¬ 
tems transmit a pulse and calculate the 
distance using the delay time before the 
reflected signal is received. Measurements 
derived from range sensors can be applied 
to many tasks. The most obvious include 
object detection, one-dimensional object 
location, and guidance tasks such as edge 
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Relating standard position to ideal position 


The matrix F represents the solution to a problem in which 
target points in standard position are viewed by a camera in 
ideal position. The coordinates of the target points in standard 
position, (X“, Y“, Z/*) r are found by applying the transform S 
to the original target points. The image coordinates of these 
points as seen by a camera in ideal position, (xA y®) T are 
found by applying the transform T 1 to the three-dimensional 
points (x„ y„ -X), producing the points (X, r , Y, r , Z/), and then 
setting x/> = -XXj/Zj and Y? = -XY'JZ;. 

F is then a transformation matrix, which is a solution to a 
problem described by 

(X/>, Y7>, 2A 1) r = F(X,“, Y", Z,“, 1) r , 

(xA y/*) r = (-xxp/zf, -XYp/zpy, 

where X/*, Y,“, 2?. *1. and y? are known for / = 0, 1,2, and 3. 
Because of the way in which we defined the a and /3 systems, 
the parameters X 0 “,Y 0 “, Z 0 “, Y,“, Z,“, Z 2 “, Z 3 “, x 0 A y 0 p , and y/ 
are all equal to zero. Substituting P 0 = (0,0,0,1 ) r into the equa¬ 
tions represented above immediately gives F 14 = F 24 = 0. Sub¬ 
stituting in the other points gives the following: 


AX,“F n 

+ x/'X'-F 

3 , + x/F 34 = 

: 0 


(i) 

AX,“F 2i 

= 0 




(2) 

AX 2 “F,, 

+ AY 2 “F I2 

+ x/X 2 “F 3 , 

+ x/y 2 “F 32 

+ x/F 34 = 0 

(3) 

AX 2 “F 21 

+ XY 2 a F 22 

+ y 2 ^x 2 “F 31 

+ y/Y 2 “F 32 

+ y/F) 4 * o 

(4) 

AX 3 “F u 

+ AY 3 “F, 2 

+ x/X 3 “F 3 , 

+ x/Y 3 “F 32 

+ x/F 34 = 0 

(5) 

ax 3 »f 21 

+ AY 3 “F 22 

+ y/x 3 »F 3l 

+ y/Y 3 “F, 2 

+ y/F 34 = o 

(6) 


We immediately see from the second of these equations that 
F 21 must be zero. 


We can solve for the remaining elements using Gaussian 
elimination in the following manner. We first take Y 3 “times Eq. 
3 minus Y 2 “ times Eq. 5 and Y 3 “ times Eq. 4 minus Y 2 a times 


Eq. 6, getting 


B,F„ + B 2 F 3 , + B 3 F 32 + B 4 F 34 = 0 

(7) 

B 5 F 3 , + B 6 F 32 + B 7 F 34 = 0 

(8) 


where 


B, = A(X 2 “Y 3 “- X 3 “V 2 “), 

B 2 = x/X 2 “ Y : " - x 3 p X 3 “Y 2 “, 
B, = (x 2 f-x 3 i')Y 2 “Y,", 

B 4 = x 2 p Y 3 “ - x 3 p Y 2 “, 

B 5 = y/X 2 “Y 3 “-y 3 f i X 3 “Y 2 “, 
B t = (y 1 e ‘-y/)Y 2 -Y 3 ", 

B, = y/Y 3 “ - y^Y 2 a . 


We next take B 6 times Eq. 7 minus B 3 times Eq. 8 getting 

B,B 6 F„ + (B 2 B 6 - B 5 B 3 )F 31 + (B 4 B 6 - B 7 B 3 )F 34 = 0 (9) 

Finally, we take (B 4 B 6 - B 7 B 3 ) times Eq. 1 minus x/ times Eq. 
9 and get 

B a F„ + B^, = 0 (10) 

where B s and B 9 are given by 

B 8 = AX,“(B 4 B 6 - B 7 B 3 ) - x/'B.Bj, 

B, = x^[X,“(B 4 B 6 - B 7 B 3 ) - (B 2 B 6 - B 5 B 3 )] 

Because the rotation submatrix of Fmust be orthonormal 
and the term F 21 was found to be zero, we also know that 

F,i 2 + F 31 2 = 1 (11) 

Using Eq. 10 and Eq. 11 we find 


1 

1+(B e /B 9 ) 2 

The sign of F„ can be determined as follows: We note that 
the point P 0 must be in front of the camera, so the transfor¬ 
mation Fmust give it a positive Z 0 p component. As P 0 is at 
the origin of the a-system, this implies that F 34 must be posi¬ 
tive. Using this, along with Eq. 1 and the fact that x/, X,“, 
and A are all positive, we find that F„ is positive if and only if 
A/x/ is less than ~F 32 /F„, where Eq. 10 indicates that XF 3 ,/ 
F„ = B e /B 9 . 

The other coefficients of Fean be found by substitution 
into the previous equations with the following results: 

F 31 = -B a F.,/B 9 

F m = - X,“(A / xf + F 31 ) 

F = f-(B 6 F 31 + B 7 F 34 )/B 6 , ifS 6 *0 

32 [-(B, F,, + B 2 F al + S 4 F 34 ) / B 3 , otherwise 

F 12 = - (A X“ F„ + x| X° F 31 + xf Y“ F 32 + x^F 34 )/(A Y“) 

F 22 = - y£ (X 2 “ F 31 + Y“ F 32 + F 34 )/(A Y 2 “) 

Because the rotation submatrix of Fis orthonormal, the ele¬ 
ments of the third column can be found using cross products 
of the elements in the first two rows, that is, 

F„ = -F 22 F 31 

f 23 = f 12 f 31 -f 11 f 32 
f 33 = f„f 22 

where product terms involving F 21 are omitted because F 21 is 
zero. This completes the evaluation of the unknown ele¬ 
ments of F. 
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following. Some systems enhance their 
capabilities by sweeping the scene in a 
one- or two-dimensional pattern to build a 
two- or three-dimensional “picture” of the 
environment. With these systems, the ca¬ 
pabilities are extended to include object 
recognition and three-dimensional object 
location. 210 

To provide range capability for our sys¬ 
tem, a range sensor is mounted on the end- 
effector next to the camera so that its sens¬ 
ing axis is parallel to the camera’s optical 
axis. The installed range device is a Po¬ 
laroid Ultrasonic Ranging Unit - a piezo- 
electric-based electroacoustic transducer 
that serves as an emitter and receiver. It 
emits a high-frequency chirp (four fre¬ 
quencies around 50 kHz) for a time win¬ 
dow of 1 millisecond. It then shuts off and 
listens for an echo reflected by nearby 
objects in the scene. The delay between the 
emitted pulse and the reflected one is pro¬ 
portional to the distance from the object 
sensed. The pulse generator and the cir¬ 
cuitry necessary for the echo detection and 
distance measurement are provided with 
the sensor. This sensor has been modified 
to accommodate the type of experiments 
undertaken in robotic inspection and ma¬ 
nipulation operations: The beam cone is 
about 5 degrees, and the accuracy for nor- 
mal-to-surface measurements is about 0.2 
inch. The robotic system also has an Odetics 
Laser Range Scanner capable of generat¬ 
ing two 128 x 128 images of range and 
intensity. This sensor is not used during the 
valve manipulation experiment. 

The sound generator/sensor that acti¬ 
vates the alarm system is similar to the 
ultrasonic range sensor. The sound gener¬ 
ator is mounted on the task panel and the 
sensor is mounted on the robot end-effec¬ 
tor. A tone of approximately 5 kHz is 
emitted when the alarm is activated. The 
sound sensor filters the signal, and the 
alarm is sensed if the filtered signal ex¬ 
ceeds a given threshold. 

Proximity sensing. Proximity sensing 
usually involves detection of a disturbance 
brought to a monitored signal by the pres¬ 
ence or absence of an object within a spe¬ 
cific volume around the sensing element. 
As opposed to range sensors, which pro¬ 
vide the actual distance between the targeted 
object and the sensor, proximity sensors 
generate only a binary output indicating if 
this distance is below or above a predeter¬ 
mined threshold. Most proximity sensors 
are inductive, magnetic, capacitive, ultra¬ 
sonic, or optical. 

This variety in sensing modalities yields 


an equal variety in characteristics. Some 
proximity sensors can detect the presence 
of objects from distances averaging sever¬ 
al feet (ultrasonic and optical); others can 
sense only within a few millimeters (in¬ 
ductive and magnetic). Capacitive, ultra¬ 
sonic, and optical sensors can detect most 
materials, although with significantly 
varying sensitivity (highly dependent on 
the material and/or surface reflection and 
orientation), whereas inductive and mag¬ 
netic sensors are sensitive only to ferrous 
metals. 

The proximity sensors used in this ex¬ 
periment are optical; they consist of three 
solid-state infrared light emitters coupled 
with three solid-state light receivers con¬ 
figured as shown in Figure 2. They are 
designed to detect the presence of an object 
between the parallel jaws of the end-effec¬ 
tor when the beam is interrupted and also to 
detect the presence of an object in front of 
the end-effector when a reflection is sensed. 
In this experiment, use of the proximity 
sensors is limited to collision avoidance 
during the manipulation phase. 

Force/torque sensing. Force and torque 
sensing generally refer to the measurement 
of the global forces and torques applied on 
a workpiece by a robot manipulator. The 
force/torque sensor used in this work is the 
Lord FT-30/100 (Figure 2). The sensor is 
designed for wrist mounting. It uses eight 
piezoresistive strain gauges that provide 
real-time feedback of the location, magni¬ 
tude, and orientation of forces and mo¬ 
ments. The system is equipped with a pro¬ 
cessor that resolves the eight raw pieces of 
data into six Cartesian component forces 
and torques at a rate of 83 Hz. The convert¬ 
ed force and torque measurements can be 
referenced with respect to any element in 
the arm including the sensor itself. This 
allows the load cancellation of the end- 
effector, sensor, or workpiece, which would 
otherwise degrade the quality of measure¬ 
ments. This system has a maximum force 
and torque capacity of 30 pounds and 100 
inch-pounds, respectively. The system res¬ 
olution is about 1 ounce and 1 inch-ounce 
for force and torque, respectively. A one- 
chip microcomputer has been added to the 
system for communication between the 
sensor and the main processor for sensor 
biasing, threshold setting, and interfacing 
to other sensors. These features are impor¬ 
tant in performing complex and time-con¬ 
suming operations. 

During the entire experiment (camera 
positioning and activation, data acquisi¬ 
tion and processing, and manipulation) the 


force/torque sensor is active. Its role is to 
continuously monitor each of the three 
force components, F„ F y , and F„ along the 
three axes, X, y, and Z, respectively, rela¬ 
tive to the robot end-effector. It also mon¬ 
itors the three components of torque, T x , T y , 
and T z . At a rate of 83 Hz, the six compo¬ 
nents, V = (F x , F r F v T x , T y , T Z ) T , are read 
and compared against a preset value, V”“. 
The robot motion is immediately halted if 
any component of force or torque exceeds 
its preset threshold. When the robot en¬ 
counters excessive force (or torque), it stops, 
waits for a preset time (5 seconds), then 
attempts to complete the task. It is worth 
noting that the threshold vector V"“ is a 
dynamic variable that can be changed at 
any time during the execution of a given 
task. For the valve manipulation experi¬ 
ment, V max was set to 

V™* = (F x , F y , F v T x , Ty, T : ) T 

= (15, 15, 15, 50, 50, 50) r 

during motion of the robot arm (no colli¬ 
sion is expected) and twice this value during 
manipulation (collision is expected). 

Touch sensing. A touch sensor can pro¬ 
vide a robot with information that can be 
crucial in many of its functions. Touch 
sensors presently used in industry are often 
simple and crude devices. As with other 
sensing modalities, the state of the art in 
touch sensing is still limited. Binary touch 
sensors, the simplest type, indicate only 
the presence or absence of an object. This 
is sometimes referred to as simple contact 
sensing or simple touch. Despite its sim¬ 
plicity, binary sensing provides valuable 
information. 210 In this work, two micro¬ 
switches are mounted inside the end-effec¬ 
tor’s textured compliant surfaces (Figure 
2). They are used primarily for detecting 
the presence or absence of a workpiece 
between the end-effector jaws. The manip¬ 
ulation experiment is halted whenever the 
actual reading is different from that ex¬ 
pected. The robot is also equipped with 16 
x 10 and 80x80 gray-scale-responsive array 
touch sensors that are not used in the valve 
manipulation experiment. 

Valve experiment 

This section illustrates the use of senso¬ 
ry cues to perform manipulation opera¬ 
tions on the control panel. We describe the 
experimental setup, list the tasks necessary 
for valve operation, and summarize the 
experiment chronologically. 
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Figure 6. Components mounted on the task panel are (1) guiding lights, (2) ana¬ 
log meter, (3) LCD analog meter, (4) valves, (5) LCD digital meters, (6) slider, 

(7) lateral analog meter, (8) tool rack, (9) control switch, (10) push-buttons, (11) 
LCD input, (12) command setting control, (13) push-buttons, (14) emergency 
knob, and (15) audible alarm. In designing this panel, colors are selected to ac¬ 
commodate both high color and intensity contrasts that are desirable in vision 
acquisition and processing, as well as low color and intensity contrasts, which are 
desirable in range acquisition and processing using a three-dimensional laser 
scanner. 


Setup. Control panel devices encoun¬ 
tered in nuclear power plants can be broad¬ 
ly classified into two categories: indicators 
and controls. Indicators are devices that 
display the status of some process. Con¬ 
trols are devices that an operator can phys¬ 
ically alter to remotely modify a process. 
Both come in different shapes and sizes. 
Since the robot’s major sensing modality is 
visual, it is important that the testbed include 
indicators and controls of different tech¬ 
nologies and shapes. Size is not a major 
factor in this selection, since object de¬ 
scriptors can often be made size-indepen¬ 
dent. As such, we can duplicate the controls 
in reduced size and avoid limiting the task 
panel’s utility. The major advantage in 
using small replicas of actual controls is 
that the force the experimental robot needs 
to exert will be small enough for the end- 
effector to handle easily. A front view of 
the task panel and a list of the components 
mounted on it are given in Figure 6. 

Indicators. Indicators used on a control 
panel are either binary or analog. Both 
types have been included on the task panel. 


Binary indicators tell whether a process is 
on or off. The robot must be able to deter¬ 
mine the three-dimensional position and 
orientation of the task panel. Six indicator 
lights, located at six precisely defined 
positions at the edges of the panel, serve 
as a guiding target. All dimensions are in 
inches. These indicators can be turned on 
or off by the main robotic control system. 
The position and orientation of the light 
targets are determined using vision sen¬ 
sors. Analog devices indicate a numerical 
value of the measured quantity. 

We used three different kinds of analog 
indicators on the task panel. The first is a 
standard analog voltmeter. It has an angu¬ 
lar sweep of 90 degrees and is used to 
indicate the number of turns on the corre¬ 
sponding control element. The second an¬ 
alog indicator is similar to the first except 
for the needle, which instead of being 
mechanical is made up of liquid crystal 
display (LCD) segments. Three 3 1/2- 
digit LCDs are also used on the panel. The 
first two LCD meters give digital readings 
of the first two analog indicators. The 
third LCD meter is controlled by two 


potentiometers, for coarse and fine con¬ 
trol. The display on this meter provides 
commands to be interpreted by the robot’s 
vision system. 

Controls. Controls are used by the oper¬ 
ator to modify a given process. One of the 
most fundamental tasks in maintenance 
and repair operations in nuclear environ¬ 
ments is valve manipulation. Hence, two 
valves, different in shape and size, but 
each having a 10-turn span, are included 
on the task panel. The control valves stand 
out 4.5 inches from the surface of the 
control panel and are 5.0 and 2.5 inches in 
diameter. The position of each valve is 
directly reflected by both an analog meter 
above the valve and a digital meter below 
it. A threshold of 7 on a scale of 10 has 
been preset on each valve; this preset value 
is not known to the robotic system. When 
this value is exceeded, an audible alarm is 
activated. This alarm is acknowledged 
(turned off) either by setting the valve 
position below the threshold or by activating 
an emergency knob. This knob stands out 
1.5 inches from the surface of the control 
panel and is about 2.5 inches in diameter. 

An additional type of control is a verti¬ 
cal lever (slider) connected to a single-turn 
potentiometer. The position reading of the 
vertical lever is indicated on the lateral 
analog meter. This meter is calibrated to 
indicate a full-scale reading when the ver¬ 
tical lever is on one extreme position and 
to indicate zero on the other extreme posi¬ 
tion. 


Task requirements. The multisensor 
robotic system has been tested with vari¬ 
ous inspection and manipulation experi¬ 
ments. We selected the valve experiment 
to show the system’s capabilities because 
it uses (to various degrees) most of the 
sensors mounted on the robot. Detailed 
steps of this experiment are given below. 

(1) The desired final valve position 
(corresponding meter reading) is given as 
an input by the operator. 

(2) The pose of the task panel (three- 
dimensional position and orientation) is 
determined using vision sensing. 

(3) The robot moves closer to the task 
panel and orients the end-effector so that 
the range sensor axis is normal to the 
panel. During this move, the force/torque 
sensor is continuously active for collision 
avoidance. (This is true during all moves 
executed by the end-effector.) 


( 
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Table 2. Valve experiment image coordinates (in pixels) 
and sensor coordinates (in inches). 


Target 

i 

j 



P 0 

32 

239 

+0.141 

+0.155 

P, 

196 

212 

-0.098 

+0.116 

P 2 

14 

76 

+0.162 

-0.072 

Pi 

174 

72 

-0.064 

-0.076 


and orientation of the task panel as well as 


(4) The estimate of the panel 
pose is fine-tuned using range 
sensing. 

(5) The robot moves toward the 
selected valve and its correspond¬ 
ing analog meter. 

(6) This analog meter is read 
using vision sensing. The vision 
system also determines the posi¬ 
tion of the valve spokes. 

(7) The difference between the 
actual meter reading and the input 
value is determined. The system 
plans a course of action to achieve 
the final valve position. 

(8) The manipulator retrieves an instru¬ 
mented end-effector from a storage rack. 
(The position of the storage element is 
known.) 

(9) The manipulator uses the end-effec¬ 
tor to retrieve a tool stored in a predeter¬ 
mined position to adjust the control valve. 

(10) The valve is adjusted according to 
the difference determined in step 7. The 
operation is halted if the force applied on 
the end-effector exceeds a preset value. 

(11) If the valve reading remains below 
the preset threshold during the manipula¬ 
tion phase, the system goes to step 15; 
otherwise, it proceeds as follows. 

(12) An audible alarm (a tone of a pre¬ 
defined frequency) is turned on. The robot 
sound sensor detects the alarm. The valve 
manipulation operation is halted. 

(13) The robot moves toward the area 
where the emergency knob is located. The 
relative two-dimensional position of the 
emergency knob with respect to the panel 
is known; however, its height is uncertain 
due to slight inaccuracies in the estimation 
of the panel orientation. 

(14) Using force sensing, the robot iden¬ 
tifies the position of the emergency knob 
and activates it, hence acknowledging the 
audible alarm. 

(15) The valve adjustment tool is re¬ 
turned to its storage rack. The end-effector 
is returned to storage. The manipulator 
arm is returned to home position. 

Task execution. The valve experiment, 
like all experiments, is specified within the 
RSC module by the goal it achieves and its 
sequence of programmed steps. The nu¬ 
merical values presented here are typical, 
though they differ for each run of the ex¬ 
periment, depending on the exact position 


the relative position and readings of the 
controls and indicators on the panel at the 
time of execution. The experiment is de¬ 
scribed chronologically to emphasize the 
autonomy aspect and give the reader a 
concrete idea of the range and character of 
the data involved in such experiments. 

Initially, the position and orientation of 
the task panel are unknown. At this point 
the robot is using a coordinate system ref¬ 
erenced to its base (Figure 3). The robot 
calculates the three-dimensional position 
and orientation of the panel based on the 
two-dimensional information supplied by 
the vision sensor. To locate the panel, the 
robot moves to a preprogrammed position 
from where it can sense at least four of the 
six light targets located on the panel. The 
task panel can be in any position or orien¬ 
tation. With the task panel in the vision 
sensor’s field of view, two images are 
acquired, one taken with the light targets 
off, the other taken with the lights on. The 
two images are subtracted, and the result¬ 
ing image shows the location of the light 
targets. Both images are 256 x 256 pixels 
— the optimal image size, considering the 
dimension of the light targets, the process¬ 
ing operations required in estimating the 
image coordinates for each point, and the 
desired accuracy in positioning the end- 
effector with respect to the task panel. In 
this particular run, the image coordinates 
(in pixels) of the four light targets are 
converted to sensor coordinates (in inches) 
using the geometry of the camera. Both 
coordinate sets are summarized in Table 2. 

Using the pose estimation technique 
described earlier, the position and orienta¬ 
tion of the panel with respect to the fixed 
coordinate system are determined. They 
are summarized in the following pose vec- 


P = (X 0 , Y 0 , Z 0 , 6, e, p) 

= (27.8, -31.5, 3.2, 91.0, 89.7, 88.7) 


The translation vector coordi¬ 
nates are in inches; the rotation 
angles, which represent Euler an¬ 
gles for pitch, yaw, and roll, are in 
degrees. For the rest of this exper¬ 
iment, all motion operations are 
performed relative to a coordinate 
system that has its origin at the 
lower left corner of the task panel, 
oriented in the manner shown in 
Figure 3. Visual sensing alone of 
the panel’s position and orienta¬ 
tion does not provide sufficient 
accuracy for manipulation tasks 
(up to about 3 percent error). To 
achieve better accuracy, the range sensor 
is used to update the perpendicular dis¬ 
tance of the manipulator from the task 
panel. The end-effector moves to a fixed 
point relative to the panel, as determined 
by the vision system (d v = 18 inches), and 
a range reading of this distance ( d r = 17.4 
inches) is taken. It has been verified ex¬ 
perimentally that the range reading is closer 
to the actual distance than is the reading 
estimated by vision sensors. According¬ 
ly, the estimated position of the panel is 
updated to reflect the disparity between 
range and vision estimates. Compliance 
built into the end-effector and tools ad¬ 
justs for the remaining misalignments 
caused by errors in these measurements. 

With the coordinate systems of the ma¬ 
nipulator and the task panel aligned, the 
robot is now ready to interact with the 
controls and indicators mounted on the 
task panel. Note that all operations per¬ 
formed under this task are sensor driven. 
The robot is performing autonomous on¬ 
line path planning as it moves the manip¬ 
ulator in either coordinate system. More¬ 
over, the robot verifies that the final goal 
of each move is within its work envelope 
and that the manipulator does not collide 
with obstacles within its workspace, in¬ 
cluding its base and the table on which the 
task panel is placed. If the robot deter¬ 
mines that a move is not possible, it out¬ 
puts a message to that effect. This is 
analogous to a mobile robot activating its 
drive base to move to an unreachable 
point. 

At this stage, the robot uses its vision 
sensor to locate the intended meter and 
corresponding valve. The vision system 
is capable of segmenting a scene showing 
an analog meter and the corresponding 
valve. The segmented image is further 
processed to identify the needle position 
of the analog meter and hence determine 
its reading. The meter reading for this 
experiment is 3.0 on a scale of 10. 8 (Recall 
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Both Zf and Zf are known from the ge¬ 
ometry of the valve, which is stored in the 
vision system knowledge base. 

At this point, the robot has acquired or 
has extracted from the knowledge base all 
the information necessary to operate the 
valve. For manipulation, the robot needs 
to use a tool, since the gripper is not large 
enough to grasp the valve directly. This 
would not have been the case if the oper¬ 
ator had selected the right (smaller) valve. 
Procedures for operating each component 
on the panel are stored in the system 
knowledge base and are accessible to the 
RSC and other modules. To retrieve the 
tool, which is stored in a tool rack, the 
robot first selects the appropriate end- 
effector (Figure 8). The instrumented end- 
effector used in this experiment is stored 
in a storage rack, the position and orienta¬ 
tion of which are known with respect to a 
fixed coordinate system. During the end- 
effector delicate mating, the force/torque 
sensor monitors the forces being applied 
to the interchange device. If the preset 
threshold for force or torque is exceeded, 
mechanical misalignment and possible 
jamming are indicated. When this occurs, 
the robot aborts the operation without 
damaging the manipulator arm and/or end- 
effector and attempts the operation again. 
Once a successful mating is achieved, the 
end-effector is mechanically locked onto 
the manipulator by a pneumatic device. 
The system’s ability to interface with in¬ 
terchangeable end-effectors that carry 
different sensors is crucial, since it in¬ 
creases sensing capabilities and hence 
the sophistication of the tasks under¬ 
taken. 

The manipulator (with the end-effector 
attached) is moved to the tool storage rack 
area and the end-effector closes on the 
handle of the tool. Both the proximity and 
touch sensors check for the presence of 
the tool between the parallel jaws of the 
end-effector. Note that moves made dur¬ 
ing end-effector interchange and tool re¬ 
trieval are performed with respect to the 
fixed robot coordinates, while moves in¬ 
volving interaction with the panel are made 
with respect to the estimated panel posi¬ 
tion and orientation. The valve is rotated 
by placing the tool end in the free space 
between the spokes and moving the ma¬ 
nipulator in a circular motion. This motion 
is obviously dictated by the geometry of 
the valve (Figure 9), and that information 
is stored in the knowledge base. 

Here also, the force/torque sensor acts 
as a safety device that aborts manipula¬ 
tion whenever excessive forces are ap- 


Figure 7. Valve and corresponding meter image used by the vision sensor for 
valve location and meter reading. The processed data is a 256 x 256 black-and- 
white image with 256 gray levels. 


that the desired final reading is 9.) The 
robot will attempt to rotate the valve six 
revolutions clockwise. If the difference 
were negative, the rotation would be 
counterclockwise. 

The valve handle consists of an outer 
ring supported by four spokes (Figure 7). 
While reading the meter, the robot also 
acquires an image of the valve from which 
the location of the Valve center, the angle 
between spokes, and the center of the up¬ 
per right-most free space between spokes 
are determined. The location of the valve 
center is determined by identifying the 
center of the segmented valve in the image. 
The reading from the image is then con¬ 
verted into three-dimensional information. 
The position of the valve center in the 
panel coordinate system is 

(Xf, Yf, Zf) = (4.58, 8.26, 4.50) 

The center of the upper right free space 
between the valve spokes is 

(X/, Yf, Zf) = (5.44, 8.88, 4.50) 


Figure 8. Robot picking up instru¬ 
mented end-effector from storage 
rack. 
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plied on the robot end-effector. Experi¬ 
mentation with this system has shown that 
this conservative strategy is the only way 
to ensure safe, autonomous task execution 
without human intervention, even if it 
takes several tries to accomplish the de¬ 
sired task. 

If the robot senses no audible alarm 
while manipulating the valve (not the case 
in the experiment illustrated here), it com¬ 
pletes the task as planned after the camera 
reading of the meter position. The task 
panel has a sound generator that emits a 
narrow-bandwidth tone when the meter 
reading corresponding to the valve being 
manipulated exceeds a preset threshold. 
Level and frequency characteristics were 
selected so as not to be mistaken for robot, 
human, or other sounds. During valve ma¬ 
nipulation, if the preset threshold is ex¬ 
ceeded and the alarm is activated, the 
robot aborts the valve manipulation task 
and prepares to acknowledge the audible 
alarm by activating the emergency knob 
mounted on the task panel. 

The x-y position of the emergency knob 
is known with sufficient accuracy; how¬ 
ever, the depth component is uncertain 
due to small errors in the estimated panel 
orientation. First, the robot aborts the valve 
adjustment operation by removing the tool 
from the control valve spokes. Second, the 
robot uses the same tool in conjunction 
with the force/torque sensors to locate and 
activate the emergency knob. The tool is 
moved perpendicular to the emergency 
knob until the force exceeds a preset value 
that corresponds to the knob’s being off. 
The tool is pushed farther until the sound 
is turned off, excessive force is required, 
or the distance travelled exceeds the emer¬ 
gency knob travel distance, the value of 
which is stored in the knowledge base. As 
a result, the alarm is deactivated (Figure 
10 ). 

After the robot has successfully adjusted 
the valve and/or deactivated the alarm, it 
returns the tool to its storage rack. This is 
done by switching to robot coordinates, 
moving the tool to a position slightly above 
the rack, and opening the gripper. This 
allows the tool to fall into the rack. The 
end-effector is returned to the storage rack 
by moving to a position slightly above the 
end-effector storage rack and deactivating 
the pneumatic clutch holding it. The end- 
effector then falls into the rack. The ma¬ 
nipulator is returned to home position and 
the robot notifies the supervisor of the 
operation’s outcome and status. Having 
completed the task, the robot awaits fur¬ 
ther commands. 


O ur experiment clearly illustrates 
the need for multisensory infor¬ 
mation to accomplish complex, 
autonomous robotic inspection and manip¬ 
ulation tasks. 

The system behavior under the condi¬ 
tions experienced in the laboratory was 
fairly robust. The experiment, conducted 
several times under varying conditions of 


lighting, audio noise, panel orientation, 
and so forth, was successfully completed 
in well over 90 percent of the trials. Few 
major problems were encountered in 
achieving this success rate. Most modifi¬ 
cations to the preliminary versions of this 
system involved fine-tuning the individual 
sensing modules. However, several limita¬ 
tions remain in the current implementation 


Figure 9. Robot setting the valve to the desired final reading. 


Figure 10. Robot acknowledging the audible alarm by deactivating the emergen¬ 
cy knob. 
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and would degrade the performance in a 
less constrained environment. These in¬ 
clude the following: 

• The task panel position and orientation 
must be confined to a fairly small area of 
the workspace: The panel must be close 
enough for the robot to perform manipula¬ 
tion tasks, yet far enough for four of the 
calibration lights to fit in a single camera 
view. Currently, the robot does not search 
for these lights. This constraint may be 
easily lifted for a mobile robot, which is the 
ultimate residing platform for these test 
experiments. 

• Correspondence between the calibra¬ 
tion lights and their images is assumed. 
This means that camera roll must be such 
that “up” in the sensed image is within 
approximately 45 degrees of “up” on the 
panel front view. 

• Because the camera was mounted on 
the end-effector, the meter was not read 
while the valve was being operated. The 
number of valve turns required was deter¬ 
mined from the initial reading. An en¬ 
hanced version of this system can involve 
continuous vision-based process monitor¬ 
ing. 

• The proximity, force/torque, and touch 
sensors performed well consistently. This 
is true in part because of their simple use in 
the experiments completed thus far. In the 
future, the complexity of the tasks under¬ 
taken will warrant a more sophisticated 
and broader use of these sensors. This will 
be particularly true with range and touch 
sensing. 

• A hardware filter was used in sensing 
the audible alarm. This filter was effective 
in removing acoustic noise (from the robot 
and human conversation), but it required 
that the alarm frequency be in a fairly 
narrow range. 

• The tool used to turn the valve was not 
rigid enough to operate valves requiring 
considerable torque. Special-purpose tools 
can be built for the interchangeable end- 
effector to cope with the variety in the 
manipulation tasks required. During our 
experimentation phase, tool characteris¬ 
tics were very crucial in the success of 
most operations. 

Note that although the valve experiment 
described here invokes a limited number of 
operations, each of the individual sensing 
tasks was handled by an independent mod¬ 
ule, so the robotic system can be easily 
used in different and more complex sce¬ 


narios. The hardware and software modu¬ 
larity of this robotic system, the generic 
nature of its building blocks, and its recon¬ 
figurability make it an ideal tool for indus¬ 
trial multisensor robotic experimentation. 

There are numerous issues that a re¬ 
searcher must address before implemen¬ 
ting a system with multisensor integration. 
The major issues include planning sensor 
use, positioning sensors, and fusing/inter¬ 
preting multisensor data. Since the data 
collection process can be overwhelming, 
planning sensor use is no trivial effort. For 
low-level tasks, it may be necessary to 
anticipate sensing and action scenarios so 
that the robot’s controller determines what 
data is most important. In deciding what 
information should be obtained, the re¬ 
searcher must determine what data is un¬ 
known and what additonal information is 
needed to verify the existing hypotheses. 

In addition, the researcher must make a 
cost/benefit analysis to determine which 
sensors will collect the necessary informa¬ 
tion. Vision, for instance, may provide a 
wealth of information, but it is computa¬ 
tionally expensive, and a simpler sensor 
may suffice. Therefore, it is necessary to 
assign a cost to the use of each sensor for 
each task and a value to the information 
obtained. 

Finally, a researcher must develop fu¬ 
sion/integration methodologies so that once 
a piece of information is acquired about a 
given scene or event using one sensor, the 
robot can (1) confirm the data of another 
source, (2) complement the data of another 
sensor, (3) provide the context of other 
data, (4) improve or update previous read¬ 
ings, (5) guide in the use of another sensor, 
and, ultimately, (6) synergistically combine 
data from one sensor with data from another 
sensor — at all levels of abstraction — 
generating information that is not available 
using either sensor alone. Our future work 
addresses these issues. ■ 
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Object-Oriented Database 
Management Systems: 
Concepts and Issues 


Elisa Bertino, University of Genova 
Lorenzo Martino, Datamont Research and Development Centre 


T he first and most relevant applica¬ 
tions of database management sys¬ 
tems technology were for business 
and administration. This influenced data 
organization and usage in DBMSs. 

Recently, however, hardware innova¬ 
tions have opened the market to new appli¬ 
cations that require adequate software tools. 
Typical examples include computer-aided 
design, office information systems, hyper¬ 
media systems, documentation of complex 
mechanical systems, knowledgebases, and 
scientific applications. 

These applications require effective 
support for the management of complex, 
possibly multimedia, objects. Forexample, 
hypermedia applications require handling 
of text, graphics, and bitmap pictures, while 
design applications might require support 
for geometric objects. Other crucial re¬ 
quirements derive from the evolutionary 
nature of applications and include multiple 
versions of the same data and long-lived 
transactions. 

The support of complex objects imposes 
several requirements on both the object 
data model and object management. The 


Object-oriented 
database technology 
combines the 
expressive power of 
programming 
languages with 
effective support for 
persistent data typical 
of database 
management systems. 


data model should support the modeling of 
object structures and interrelationships in a 
natural way. The model should support not 
only an object structural definition, but 
also the modeling of object behaviors and 


dynamic constraints. In addition, in the 
intended application environments, the 
object structures, behavior, and interrela¬ 
tionships evolve over time. 

From the object management viewpoint, 
the application characteristics, the object 
dimensions, and the length of operations 
require extending or completely modify¬ 
ing traditional DBMS architectures, tech¬ 
niques, and algorithms to deal with a num¬ 
ber of issues. For instance, 

• Two modalities of access to objects 
should be provided (that is, access to a 
single object) based on some object identi¬ 
fier or name, and access to sets of objects, 
based on declarative queries. 

• Object versioning mechanisms should 
be provided to take into account different 
object evolution states, validity times, and 
information about alternatives. 

• Transactions can extend in time and 
involve large amounts of data. This requires 
revisiting the recovery and concurrency 
control mechanisms. 

• The evolutionary nature of applica¬ 
tions makes schema modification the norm 
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rather than the exception. Therefore, exe¬ 
cution of schema modification operations 
should be supported without requiring sys¬ 
tem slowdown or shutdown. 

• Protection mechanisms should be based 
on the object, which is the natural access 


To satisfy these requirements, one di¬ 
rection undertaken in the database area 
is the design and development of object- 
oriented database management systems 
(OODBMSs). An object-oriented data 
model lets the user model every conceptual 
entity by using a single modeling concept: 
the object. In addition, mechanisms such 
as aggregation and generalization let the 
user represent relationships among objects, 
and among object collections. 

The object-oriented paradigm was pri¬ 
marily introduced in the design of advanced 
programming languages and environments 
such as Smalltalk. A first attempt to apply 
this paradigm to data management has re¬ 
sulted in the building of object-oriented 
interfaces on top of relational DBMSs. 
Mainly for performance reasons, this so¬ 
lution is generally unsatisfactory. 

More advanced systems, such as Avance, 1 
Encore, 2 Gemstone, 3 Iris, 4 0 2 , 5 Orion, 6 and 
Vbase, 7 have taken the approach of de¬ 
signing an architecture to directly support 
the object-oriented paradigm. 

Basic concepts of an 
object-oriented data 
model 

The object-oriented paradigm is based 
on five fundamental concepts: 

(1) Each real-world entity is modeled 
by an object. Each object is associ¬ 


ated with a unique identifier. 

(2) Each object has a set of instance 
attributes (instance variables) and 
methods; the value of an attribute 
can be an object or a set of objects. 
This characteristic permits arbi¬ 
trarily complex objects to be de¬ 
fined as an aggregation of other 
objects. The set of attributes of an 
object and the set of methods repre¬ 
sent the object structure and behav¬ 
ior, respectively. 

(3) The attribute values represent the 
object’s status. This status is accessed 
or modified by sending messages to 
the object to invoke the correspond¬ 
ing methods. 

(4) Objects sharing the same structure 
and behavior are grouped into classes. 
A class represents a template for a 
set of similar objects. Each object is 
an instance of some class. 

(5) A class can be defined as a special¬ 
ization of one or more classes. A 
class defined as a specialization is 
called a subclass and inherits at¬ 
tributes and methods from its 
superclass(es). 

However, there are many variations with 
respect to these five concepts, as we will 
see in the remainder of this section. In fact, 
we use them mainly as a way to organize 
the discussion, rather than as a definition 
of the object-oriented paradigm. 

An OODBMS can be defined as a DBMS 
that directly supports a model based on the 
object-oriented paradigm. Like any DBMS, 
it must provide persistent storage for objects 
and their descriptors (schema). The system 
must also provide a language for schema 
definition and for manipulation of objects 
and their schema. In addition to these basic 
characteristics, an OODBMS usually in¬ 
cludes a query language and the necessary 
database mechanisms for access optimiza¬ 


Glossary 


CLOS 

Common Lisp Object System 

Codasyl 

Conference on Data Systems Languages 

DBMS 

Database management system 

ESPRIT 

European Strategic Programme for Research in Information 


Technology 

OID 

Object identifier 

OODBMS 

Object-oriented database management system 

OOPL 

Object-oriented programming language 

RID 

Record identifier 


tion, such as index and clustering, concur¬ 
rency control and authorization mecha¬ 
nisms for multiuser accesses, and recov¬ 
ery. 

Objects and object identifiers. In ob¬ 
ject-oriented systems, each real-world en¬ 
tity is uniformly represented by an object. 
Each object is uniquely identified by an 
object identifier. The identity of an object 
has an existence independent of its value. 
Using OIDs lets objects share subobjects 
and makes possible the construction of 
general object networks. 

The notion of an object identifier is 
different from the concept of key in the 
relational data model. A key is defined by 
the value of one or more attributes and, 
therefore, can undergo modifications. But, 
two objects are different if they have dif¬ 
ferent object identifiers, even if all their 
attributes have the same values. Note that 
sharing objects in models where identity is 
based on value leaves the applications to 
manage key values and the associated 
normalization problems. 

However, there are models in which both 
objects and values are allowed; in these 
models not all entities are objects. Infor¬ 
mally, a value is self-identifying and has 
no associated OID. In some models, all the 
primitive entities, such as integers or char¬ 
acters, are values, while all other entities 
are objects. 

Other models, notably Avance' and 0 2 , 5 
provide the possibility of defining complex 
(or structured) values. Complex values 
cannot be shared among objects. They are 
built using the same constructors as those 
provided for objects. We discuss these later. 

In general, complex values are useful in 
situations where aggregates (or sets) must 
be defined to be used as components of 
other objects but will never be used alone. 
If complex values are not allowed, these 
aggregates must be defined by using a class 
and must have an OID associated with 
them. Therefore, some performance penalty 
is incurred. 

An example is dates. Suppose that a date 
is defined as a tuple of three components, 
respectively representing month, day, and 
year. Dates are likely to be used as com¬ 
ponents of other objects. However, it is 
unlikely that a user will issue a query on the 
class of all dates. Therefore, it appears 
more convenient to define dates as com¬ 
plex values rather than as objects. 

The notion of object identity introduces 
at least two different notions of equality 
among objects. The first, denoted here by 
=, is the identity equality. Two objects are 


34 


COMPUTER 








identity-equal, or identical, if they have the 
same OID. 

The second, denoted here by ==, is the 
value equality. Two objects are value-equal 
if all their attributes that are values are 
equal and all their attributes that are obj ects 
are recursively value-equal. That is, the 
two objects have the same content, even if 
they have two different identifiers. Two 
identical objects are also value-equal, but 
two value-equal objects are not necessarily 
identical. 

Different approaches for building OIDs 
can be devised. For example, in the approach 
used in the Orion system, 6 an OID consists 
of the pair <class identifier, instance 
identifier. The first element is the identifier 
of the class to which the object belongs, 
and the second identifies the object within 
the class. 

The complete definition of attributes and 
methods for all instances of a class is fac¬ 
tored and kept in an object representing the 
class itself (called a class-object). When a 
message is sent to an object, the system 
extracts the class identifier from the object 
identifier and accesses the class-object to 
determine the message validity and fetch 
the corresponding method. This approach 
has the major disadvantage of making ob¬ 
ject migration from one class to another 
(for example, in cases of object reclassifi¬ 
cation) difficult or even impossible, since 
this would require the modification of all 
object identifiers. Therefore, all references 
to migrated objects would be invalidated. 

In another approach, used for example 
in the Iris system, the OID does not contain 
the class identifier. The identifier of the 
class to which an object belongs is gener¬ 
ally kept as control information stored in 
the object itself. To determine whether a 
message is valid for a given object, the 
system must first fetch the object and then 
retrieve from it the class identifier. There¬ 
fore, nonvalid messages cause useless object 
accesses, and type checking is rather ex¬ 
pensive. 

In both previous approaches, the OID is 
logical; that is, it does not contain any 
information about the object location on 
secondary storage. Therefore, a corre¬ 
spondence table exists for mapping OIDs 
onto physical addresses. 

Based on physical identifiers, 0 2 5 uses a 
different approach, in which each object is 
stored in a Wisconsin Storage Subsystem 
record and the OID is the record identifier. 
The RID does not change even if the record 
is moved to a new page, for example, when 
the record grows too big for the page it 
resided on. A forward marking technique 



The values of an object’s 
attributes can be other 
objects, both primitive and 
nonprimitive. 


(as in the relational systems System R and 
Ingres) handles cases of records that are 
moved to different pages. 

The approach used in 0 2 has the main 
advantage that persistent OIDs are provided 
that support fast access to objects, since 
there is no need to map the OID on the 
physical location. The major disadvantage 
is that a temporary OID must be assigned 
to an object created on a site different from 
the object store site (for example, on a 
workstation). 

To avoid excessive message exchange, 
the permanent OID is assigned only when 
the object is stored in the corresponding 
Wiss record, at transaction commit time. 
This implies that all references generated 
during the transaction to newly created 
objects must be updated at transaction 
commit time. 

The OID can also contain object location 
for distributed databases. For example, in 
the distributed version of the Orion system, 6 
the OID contains the identifier of the site 
where the object was created. When an 
object migrates to a different site, its OID 
does not change. The object creation site 
keeps information concerning the new 
storage site of the object, so messages can 
be appropriately forwarded to the object. 

Aggregation. The values of an object’s 
attributes can be other objects, both prim¬ 
itive and nonprimitive. When the value of 
an attribute of an object O is a nonprimitive 
object O', the system stores the OID of O' 
in O. When complex values are supported 
by the model, the system usually stores in 
the object attribute the entire complex value. 

Using complex values as components is 
more efficient than using objects. In the 
first case, once an object O is fetched, all 
components that are complex values are 
usually fetched as well. When objects are 
used as components, the object O contains 
only the OIDs of its components. 

Additional access messages might be 
needed to retrieve the component objects. 
Therefore, the data model might provide 


the possibility of defining complex values. 
As pointed out in Bjornerstedt and Hulten, 1 
depending on these differences, the data¬ 
base designer can implement an entity as 
an object or as a complex value, if the data 
model supports both. More sophisticated 
strategies, however, are used when (com¬ 
plex) values are large (typically larger than 
the page size), such as in the case of mul¬ 
timedia data types. In this situation, the 
value is not stored with the object of which 
it is a component. Deux describes an ex¬ 
ample of storage strategy for large (com¬ 
plex) values. 5 

In defining complex objects and values, 
different constructors can be used. A 
minimal set of constructors that should be 
provided by a model includes set, list, and 
tuple. 8 In particular, the set constructor 
allows multivalued attributes and set objects 
to be defined. The list is similar to the set, 
but it imposes an order on the elements. 
Finally, the tuple constructor is important 
because it provides a natural way to model 
properties of an object. 

As discussed in Atkinson et al., 8 the 
object constructors should be orthogonal; 
that is, any constructor should be applica¬ 
ble to any object, including, of course, 
objects constructed using any constructor 
whatsoever. We note that some models 
impose the constraint that the tuple be the 
first-level constructor. This implies, for 
example, that when defining a set object, 
the object must be defined as a tuple of a 
single attribute, which is in turn defined as 
a set. 

The notion of composite objects is found 
in some data models. As we stated, a 
complex object can recursively reference 
any number of other objects. The references, 
however, don’t imply any special seman¬ 
tics that can be of interest to different 
classes of applications. 

One important relationship that could be 
superimposed on the complex object is the 
part-of relationship, that is, the concept 
that an object is part of another object. A 
set of component objects forming a single 
entity is a composite object. 

A similar concept is found in Atkinson 
et al., 8 where two different types of refer¬ 
ences are defined: general and is-part-of 
The part-of relationship among objects 
has some consequences on object opera¬ 
tions. For example, if the root of a composite 
object is removed, all component objects 
are deleted. 

Moreover, in some models of composite 
objects, an object can be part of only one 
object; that is, the part-of relationship im¬ 
poses an exclusivity constraint. In some 
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systems, a lock on the root of a composite 
object is propagated to all the components. 

Some extended relational models and 
object-oriented programming languages (for 
example, the Loops language) also provide 
the notion of composite objects. However, 
in some models and papers, the term com¬ 
plex object means the composite object. 

Methods. Objects in an object-oriented 
database are manipulated using methods. 
In general, a method definition consists of 
two components. The first is the method 
signature, specifying the method name, the 
names and classes of the arguments, and 
the class of the result, if there is one. 

Some systems, like Orion, 6 don’t re¬ 
quire the class of the arguments and the 
results to be declared. This happens when 
type checking is executed at runtime and 
there is therefore no need to know this 
information in advance. 

The second component is the method 
implementation, consisting of code written 
in some programming language. Different 
OODBMSs use different languages for 
method implementation. For example, both 
Vbase and 0 2 use the C language, while 
Orion uses Lisp. Gemstone uses Opal, which 
is nearly identical to Smalltalk. 

In addition to the method signature and 
implementation, other components can be 
present in a method definition. For exam¬ 
ple, in Vbase a method definition can specify 
some trigger methods in addition to the 
base method and exceptions that can be 
raised by the method execution. Trigger 
methods are often used to augment the 
semantics of inherited methods and system- 
defined methods — for example, the cre¬ 
ation and deletion methods. 

The language used to write methods is 
also used to write applications. In addition, 
some systems provide access to the database 
from conventional languages. Gemstone, 
for example, supports access from C and 
Pascal. 

Often, an object’s attributes cannot be 
directly accessed in object-oriented pro¬ 
gramming languages. The only way to ac¬ 
cess attributes is to invoke the methods 
available at the object interface (strict en¬ 
capsulation). 

In databases, a lot of applications read or 
write attribute values. Queries are often 
expressed as Boolean combinations of 
predicates on attribute values. Therefore, 
most OODBMSs provide direct access to 
attributes by means of system-defined 
methods. Examples of these methods are 
“get” and “set” of Vbase, 7 used to respec¬ 
tively read and write a given attribute. 


Objects in an object- 
oriented database are 
manipulated using 
methods. 


These methods, provided as part of the 
system, have an efficient implementation 
and save the user from having to write a 
large amount of trivial code. The major 
drawback of providing these system-defined 
methods is that an object attribute must 
sometimes be manipulated only through 
some user-defined methods. If, however, 
these system-defined methods are available, 
nothing prevents a user from using the 
system-defined method rather than the user- 
defined method (unless the users employ 
authorization or they’re disciplined). 

Therefore, some systems (for example, 
Vbase 7 and the system described in Berti- 
no et al. 9 ) let the user redefine the imple¬ 
mentation of these methods for a given 
attribute. Each time the attribute is accessed, 
the user-defined method implementation 
is invoked, instead of the system-defined 
implementation. This allows the right se¬ 
mantics to be imposed, when needed, on 
the system-defined methods. Moreover, as 
discussed in Andrews and Harris, 7 this 
capability is useful when importing data 
from external databases. 

In 0 2 , it is possible to make attributes 
visible from outside objects on user demand. 
Two special clauses of the class definition 
language, public read and public write, 
provide the function of making attributes 
directly available for reading and writing. 
If the public read (and, respectively, pub¬ 
lic write) clause is associated with an at¬ 
tribute of name Aname appearing in the 
definition of a class C, the system makes 
the attribute public for reading (and, re¬ 
spectively, writing). 

In OODBMSs characterized by distrib¬ 
uted or client-server architectures, an im¬ 
portant architectural issue concerns the site 
where an invoked method is executed. In 
Gemstone, 3 for example, the application 
designer has the option of moving an ob¬ 
ject on which a method has been invoked to 
the workstation (and then executing the 
method locally) or executing the method 
remotely on the server. 

A similar option is provided in the 0 2 


system. In general, the choice concerning 
the method execution site can be rather 
complex, since different factors must be 
taken into account, such as the complexity 
of the manipulations executed on the object, 
the references made to other objects during 
method execution, the network bandwidth, 
and the competition for the network and for 
the server. 

Classes and instantiation mechanisms. 

Instantiation is the first reusability mech¬ 
anism (the second is inheritance) in that 
instantiation makes it possible to reuse the 
same definition to generate objects with 
the same behavior and structure. Object- 
oriented data models provide the concept 
of class as the instantiation basis. A class is 
an object that acts as a template. As such, 
a class specifies the intended purpose of its 
instances by defining 

• a structure, that is, a set of instance 
attributes (or instance variables); 

• a set of messages that define the exter¬ 
nal interface; and 

• a set of methods that are invoked by 
messages. 

In this sense, the class can be viewed as a 
specification for its instances. Since the 
class factors the definitions of a set of 
objects, it is also an abstraction mechanism. 

Given a class, it is possible to generate 
through the instantiation mechanism ob¬ 
jects that answer all messages defined in 
the class. The system keeps the attribute 
values for each object separately. Repli¬ 
cating the message and method definitions 
is not necessary. These are kept in the class 
object, since they are the same for all the 
class instances. 

All instances of a given class have the 
same structure and behave similarly. The 
0 2 system, however, lets exceptions be 
defined at instance level. In 0 2 , an instance 
can have additional attributes and methods. 
Additional methods characterize the ex¬ 
ceptional behavior of an instance. If an 
additional method has the same name as a 
method defined at class level, the instance 
method definition overrides the method 
definition provided at class level. 

An alternative approach to instantiation 
is using prototypical objects. This involves 
generating a new object starting from an¬ 
other existing object by modifying its at¬ 
tributes and/or its behavior. Therefore, a 
prototype is an individual object containing 
its own description; a prototype can also be 
used as a model for creating other objects. 

This approach is useful when objects 
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evolve (that is, modify their structures and 
behaviors) quickly and are characterized 
more by their differences than their simi¬ 
larities. The approach i£ also useful when 
there are few instances for each class. In 
this way, the proliferation of many classes, 
each with few instances, is avoided. 

In general, the approach based on the 
instantiation mechanism is more appropriate 
for mature application environments in 
which the object properties and behaviors 
are consolidated. In fact, the approach based 
on instantiation makes it more complicat¬ 
ed to experiment with alternative object 
structures and behaviors. 

The prototype-based approach appears 
more appropriate in the initial phase of 
application design, in application envi¬ 
ronments that evolve quickly with fewer 
consolidated objects, and in applications 
in which classes have few instances. 

OODBMSs have usually adopted the 
instantiation approach since, in most cas¬ 
es, database applications have a lot of in¬ 
stances of each class for which an efficient 
storage organization must be provided. 
However, expect the broadening of the 
scope of database applications to also re¬ 
sult in the use of prototypical objects or 
similar mechanisms. 

So far, we have implicitly assumed that 
an object is an instance of only one class. 
However, in some models, the instances of 
a class C are also members of the super¬ 
classes of C. As Moon shows, 10 we dis¬ 
tinguish between the notions of instance of 
a class and member of a class. 

An object is an instance of a class C if C 
is the most specialized class associated with 
the object in a given inheritance hierarchy. 
An object is a member of a class C if it is an 
instance of C or some subclass of C. 

Most object-oriented data models re¬ 
strict each object to being an instance of 
only one class, even though they let an 
object be a member of several classes 
through inheritance. However, object-ori¬ 
ented data models 2 can be found that let an 
object be an instance of several classes. 

As an example, consider a class Person 
with subclasses Student and Pilot, and the 
case of a person P being a student and a 
pilot. This situation can be easily modeled 
by associating both classes with P. There¬ 
fore, P will be an instance of both Student 
and Pilot and will also be a member of 
Person through the inheritance hierarchy. 

These models provide name qualifica¬ 
tion mechanisms to solve ambiguities de¬ 
riving from attributes and methods, with 
the same name being used in the classes of 
which an object is an instance. Note, 


however, that even if the data model im¬ 
poses the restriction that each object is an 
instance of only one class, multiple inher¬ 
itance (discussed later in this article) can 
be used to handle situations like the one 
described above. For example, we could 
define a subclass Student-Pilot, having as 
superclasses both Student and Pilot, and 
make P instance of this subclass. 

In all object-oriented database models, 
each attribute has associated a domain 
specifying the class of the possible objects 
that can be assigned to it as values. This 
differs from certain programming lan¬ 
guages, such as Smalltalk, in which instance 
variables don’t have an associated type. 
For data management applications requir¬ 
ing efficient management of persistent data 
to allocate the appropriate storage and ac¬ 
cess structures, the system must know the 
types of the possible values taken by at¬ 
tributes. Thus, even the Gemstone system, 
derived from Smalltalk, requires the dec¬ 
laration of the instance variable domains in 
certain cases. 

The fact that an attribute of a class C has 
a class C as domain implies that each in¬ 
stance of C takes an instance of class C, or 
of any subclass of C, as the value of the 
attribute. This establishes an aggregation 
relationship between the two classes. 

An aggregation relationship from class C 
to class C specifies that Cis defined in terms 
of C. Since C is in turn defined in terms of 
other classes, the definition of a class C 
results in an aggregation hierarchy. An ag¬ 
gregation hierarchy can contain cycles, since 
classes can be recursively defined. 

An important question concerning in¬ 
stances and classes is whether an object 
can change class. The ability to change the 
class of objects provides support for object 
evolution. It lets an object change its 
structure and behavior and still retain its 
identity. The Encore, 2 Gemstone, 3 and Iris 4 
systems provide this capability, while most 
of the other OODBMSs don’t. 

A domain constraint problem arises when 
objects are allowed to change class. As 
discussed earlier, the value of an attribute 
A of an object O can be another object O'. 
If O’ changes class, and its new class is not 
compatible with the class domain of A, O 
will contain an incorrect object as the value 
of A. A possible solution, illustrated by 
Zdonik, 2 consists of placing a tombstone in 
O’ to indicate that the object has changed 
class. The major disadvantage of this solu¬ 
tion is that the applications must contain 
code to handle the exception of the refer¬ 
enced object being an instance of a class 
other than the expected one. 


In addition to acting as a template, the 
class in some systems also denotes the 
collection of all its instances, that is, its 
extension. This is important because the 
class becomes the base on which queries 
are formulated. 

The concept of query has meaning only 
if applied to sets of objects. In systems 
where the class does not have this exten- 
sional function, the model provides set 
constructors for object grouping. Queries 
are then issued on the sets defined by these 
constructors. In this respect, there are dif¬ 
ferences among the various systems. For 
instance, 

• In some systems, for example Gem¬ 
stone, 3 the class has only the specifi¬ 
cation meaning. A collection con¬ 
structor groups objects of the same 
class. It is also possible to define sev¬ 
eral collections all containing instances 
of the same class. Queries are issued 
on object collections. Moreover, in¬ 
dexes are defined on collections and 
not on classes. 

• In other systems, for example Orion, 6 
the class has a meaning of both speci¬ 
fication and extension. 

• Finally, other systems, for example 
0 2 , 5 provide the notions of type and 
class. In 0 2 , instances of type are val¬ 
ues and therefore don’t have OIDs (that 
is, types generate complex values), 
while instances of class are objects. 
Moreover, in 0 2 a class has associated 
its extension only if explicitly required 
by the user in the class definition 
(through the special keyword with 
extension). Therefore, in 0 2 the class 
has an extensional function only if re¬ 
quired by the user. 

In general, we find the notion of decou¬ 
pling specification from the notion of ex¬ 
tension correct. The major drawback is 
that the data model becomes more complex 
compared to a simpler model in which the 
class acts both as object template and ob¬ 
ject extent. 

Metaclasses. If each object is an instance 
of a class, and a class is an object, the 
model should provide the notion of meta¬ 
class. A metaclass is the class of a class. 
Metaclasses are crucial to support expert 
systems and AI applications. However, most 
OODBMSs don’t provide metaclasses. 

Finally, some data models provide the 
possibility of defining attributes and 
methods that characterize the classes as 
objects. Such attributes and methods, called 
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class-attributes and class-methods, speci¬ 
fy the properties and behavior of the class 
and not of its instances. As such, they are 
not inherited by the instances of a class. An 
example of a class-attribute would be an 
attribute containing the average of an at¬ 
tribute value, evaluated on all instances of 
a class. 

Inheritance. The concept of inheritance 
is a second reusability mechanism. It lets a 
class, called a subclass, be defined starting 
from the definition of another class, called 
the superclass. The subclass inherits the 
superclass attributes, methods, and mes¬ 
sages. In addition, a subclass can have 
specific attributes, methods, and messages 
that are not inherited. Moreover, the sub¬ 
class can override the definition of the 
superclass attributes and methods. 

Therefore, the inheritance mechanism 
lets a class specialize another class by 
additions and substitutions. Inheritance 
represents an important form of abstraction, 
since the detailed differences of several 
class descriptions are abstracted away and 
the commonalities factored out as a more 
general superclass. 

A class can have several subclasses. Some 
systems let a class have several superclasses 
(multiple inheritance), while others impose 
the restriction of a single superclass (single 
inheritance). Based on inheritance, the set 
of classes in the schema can be organized 
in an inheritance graph (orthogonal to the 
aggregation hierarchy). The inheritance 
graph is a tree when the model does not 
provide multiple inheritance. Unlike the 
aggregation hierarchy, an inheritance graph 
might not have cycles. 

The possibility of defining a class from 
other classes simplifies the task of class 
definition. However, it can cause conflicts, 
especially in the case of multiple inheritance. 
If the name of an attribute (or method) 
explicitly defined in a class is the same as 
an attribute of a superclass, the attribute 
from the superclass is not inherited; that is, 
the definition in the subclass overrides the 
superclass definition. 

If the model provides multiple inheri¬ 
tance, other types of conflict can arise. For 
example, two or more superclasses might 
have an attribute with the same name but 
different domains. 

Usually, rules are defined for solving 
conflicts. If the domains in the superclasses 
are related by inheritance relationships, 
the most specific domain is chosen for the 
subclass. If the domains are not related by 
inheritance, the user can specify from which 
superclass the attribute must be inherited. 


Inheritance represents an 
important form of 
abstraction, since the 
detailed differences of 
several class descriptions 
are abstracted away and 
the commonalities factored 
out as a more general 
superclass. 


In 0 2 , for example, the name of an at¬ 
tribute in a subclass can be followed by the 
from clause containing the superclass from 
which the attribute definition must be in¬ 
herited. If the user does not specify the 
inheritance paths, the solution used in most 
models is to inherit the attributes (or 
methods) based on an order of precedence 
among superclasses. 

In the last two cases, questions might 
arise on the validity of inherited methods. 
An inherited method can contain in its 
implementation a reference to an attribute 
A. This attribute, however, has not been 
inherited in a given subclass C, since an 
attribute with the same name but different 
domain has been inherited in the subclass 
from a different superclass. 

When the inherited method is invoked 
on an instance of the subclass, inconsis¬ 
tencies can arise when the semantics and 
properties of A are not those expected in 
the method. 

As mentioned earlier, the inheritance 
mechanism lets the implementation of an 
inherited method be overridden in the 
subclass. This is accomplished by defining 
in the subclass a method with the same 
name and a different implementation. 

Each time a message is sent to an instance 
of the subclass, the implementation local 
to the subclass will be used to execute the 
method. This results in a single name de¬ 
noting different method implementations. 
However, this unit of change (that is, the 
entire method) can be too coarse, since in 
some situations it might be desirable to 
refine the object behavior rather than 
completely change it. 

Mechanisms to accomplish this have been 
proposed in the framework of object-ori¬ 
ented programming languages. For exam¬ 


ple, Smalltalk supports procedural combi¬ 
nation of new and inherited behavior 
through the pseudovariable send super 
(denoted as <— Super). When you use send 
super during the execution of a method 
invoked by a message m, the superclass 
method answering message m is invoked. 

The CLOS language 10 provides mecha¬ 
nisms supporting declarative method com¬ 
binations, based on the notions of before 
method, primary method, and after meth¬ 
od. All before methods are invoked before 
the primary method, whereas all after 
methods are invoked after the primary 
method. 

Before and after methods are subject to 
some limitations in that they cannot mod¬ 
ify the control structure or the results of the 
primary method. In addition, CLOS pro¬ 
vides “around” methods supporting pro¬ 
cedural method combinations. An around 
method, if applicable, takes precedence 
over all other methods and controls whether 
and when all other methods are called. 
Moreover, an around method can modify 
the input parameters and results of the 
methods it invokes. 

Vbase 7 is an OODBMS that provides 
procedural method combination and a 
pseudovariable *$$’ for this purpose. As 
discussed earlier, a method definition in 
this system can contain a base method and 
an arbitrary number of trigger methods. 

When a method is invoked, the first 
trigger method is actually invoked. This 
trigger method then transfers the control to 
the next method by using the *$$’ syntax. 
The next invoked method is the next trig¬ 
ger method, or the base method, if there are 
no more trigger methods. 

Once the base method is executed, the 
superclass method is invoked. Therefore, 
in Vbase there is a fixed invocation order: 
first all trigger methods, on the basis of 
their declaration order in the method def¬ 
inition, then the base method, and finally 
the superclass method. 

When there are no trigger methods, the 
*$$’ pseudovariable behaves like the 
<— Super of Smalltalk. This method com¬ 
bination is procedural, since the control to 
the next method must be explicitly passed 
by using the *$$’ syntax. Therefore, the 
first invoked method might decide, on the 
basis of certain conditions, to return from 
the execution without invoking the other 
methods. 

Often, the notion of subtyping is also 
found in OODBMSs. It is important, 
however, not to confuse inheritance with 
subtyping, even if there is often a unique 
mechanism providing both functions. 
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Figure 1. A database schema example. 


For this discussion, we briefly charac¬ 
terize the difference between these two 
concepts as follows. Inheritance is a reus¬ 
ability mechanism allowing a class to be 
defined from another class, possibly by 
extending and/or modifying the superclass 
definition. A type T, on the hand, is a 
subtype of a type T if an instance of T can 
be used in place of an instance of T. 
Therefore, subtyping is characterized by a 
set of rules ensuring that no type violations 
occur when the instance of a subtype T 
replaces an instance of a supertype of T. 

The fact that a class C is a subclass of a 
class C' does not necessarily imply that C 
is also a subtype of C'. Subtyping, how¬ 
ever, influences inheritance, since it can 
restrict the overriding and can impose 
conditions on multiple inheritance so that 
the subtyping rules are not violated. An 
example of restriction on overriding is the 
requirement that when the domain of an 
attribute is redefined in a subclass, this 
domain must be a subclass of the domain 
associated with the attribute in the super¬ 
class. Wegner discusses inheritance and 
subtyping. 11 

For this article, we distinguish between 
behavioral and structural (or inclusion) 
subtyping. In behavioral subtyping, a type 
T is a subtype of T if T provides methods 
with the same name and the same (or 
compatible) arguments as T (and possibly 
additional ones). 

The criteria for behavioral subtyping are 
often based on the notion of conformity. 12 
Conformity can only be used when the 
method signatures include the types of ar¬ 
guments and the result. In structural sub¬ 
typing, a type T is a subtype of T if T 
provides the same attributes as T or at¬ 
tributes compatible with those of T (and 
possibly additional ones). 

Usually, most OODBMSs enforce only 
structural subtyping, even if subclasses 
inherit both attributes and methods from 
the superclasses. For example, the 0 2 
system 5 uses structural subtyping, while 
methods use a condition different from 
conformity. This condition leads to a less 
restrictive type system that does not guar¬ 
antee that an instance of a subclass can 
always be safely used in place of an instance 
of a superclass. Instead, the Vbase system 7 
enforces both structural and behavioral 
subtyping, using the notion of conformity. 

An example. An object-oriented data¬ 
base schema can be represented as a graph. 
In the representation in Figure 1, a node 
(denoted by a box) represents a class. A 
class node contains the names of all instance 


attributes and methods. The latter are un¬ 
derlined. Finally, the class-attributes (and 
methods) are distinguished from the instance 
attributes (and methods) by showing them 
on a darker background. 

Nodes can be connected by three types 
of arcs. An arc from class C to C indicates 
different relationships between the two 
classes, depending on the arc type. A nor¬ 
mal arc (that is, nonbold and nonhatched) 
indicates that C is the domain of an at¬ 
tribute A of C, or that C is the domain of 
the result of a method Af of C. A bold arc 
indicates that C is the superclass of C'. A 
hatched arc indicates that C is the class of 
an input parameter for some method M of 
C'. 

In Figure 1, we assume that in the Team 
class there is a method. Project budget. 
This method is applied to a Team and 
receives as an input parameter a Project; 
the method output is an integer that repre¬ 


sents the amount of budget allocated by the 
Team on the Project. Moreover, we assume 
that a class-attribute, called Maximum sal¬ 
ary, is defined for class Permanent. This 
attribute defines the maximum monthly 
wage that can be assigned to a permanent 
employee without requiring special au¬ 
thorization and checking. The class-attribute 
Maximum wage of class Consultant has a 
similar meaning. 

Comparison with semantic data mod¬ 
els. Semantic data models have been a 
relevant research topic 13 in the database 
systems area. These models are character¬ 
ized by having a greater expressive power 
than the relational, hierarchical, and network 
data models. 

Usually, a semantic data model has 
mechanisms such as aggregation, special¬ 
ization, and generalization, and it can 
therefore be considered similar to an ob- 
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ject-oriented data model. In a brief discus¬ 
sion, Hull and King characterize the differ¬ 
ences between the two types of model. 13 In 
general, the main difference is that the goal 
of semantic models is to provide mecha¬ 
nisms for structural abstraction. 

From this viewpoint, semantic models 
are close to knowledge representation 
models (like KL-One 14 ). The major goal of 
object-oriented data models is to provide 
mechanisms for behavioral abstraction. 
Therefore, they are similar to program¬ 
ming languages. However, this distinction 
is not sharp, and advanced object-oriented 
database models are characterized by having 
powerful mechanisms to support both types 
of abstraction adequately. 

Comparison with relational and Co- 
dasyl data models. The differences be¬ 
tween an object-oriented data model and 
traditional database models should already 
be clear from the previous discussion. We 
briefly summarize them here. 

The relational model differs from an 
object-oriented data model in that it does 
not provide the possibility of directly mod¬ 
eling complex objects (since attribute do¬ 
mains can only be primitive domains), and 
of defining inheritance relationships among 
sets of entities. Furthermore, it doesn’t 
provide mechanisms to associate object 
behaviors with object definitions at sche¬ 
ma level. 

The semantics of object behavior are 
dispersed among the application programs. 
Finally, object identity independent from 
object status is not supported. Nested re¬ 
lational models overcome only the first of 
these limitations in that they allow the 
definition of complex objects but lack in¬ 
heritance, object identity, and computational 
completeness. 

The Codasyl data model lets complex 
objects be defined and supports some form 
of object identity. However, as pointed out 
in Atkinson et al., 8 the object constructors in 
Codasyl are not orthogonal. Moreover, re¬ 
lationships are restricted to l:n; therefore, 
object identity is not treated uniformly. 

In addition, the Codasyl model does not 
provide concepts such as methods and class 
hierarchies. The most significant differ¬ 
ence between traditional database models 
and the object-oriented model is that the 
latter describes not only object structures 
but also their behaviors. 

Comparison with object-oriented 
programming languages. The object- 
oriented paradigm was introduced pri¬ 
marily in the field of programming lan- 



The major goal of object- 
oriented data models is to 
provide mechanisms for 
behavioral abstraction. 


guages. Several object-oriented program¬ 
ming languages (OOPLs), such as Small¬ 
talk, CLOS (defined as an extension of 
Common Lisp), and C++ (defined as an 
extension of C), can be found. The 
OODBMSs share many characteristics 
with OOPLs. Actually, some OODBMSs 
were defined starting from existing OOPLs 
(for example. Gemstone was defined from 
Smalltalk). 

An OODBMS, however, differs from an 
OOPL in that its focus is to efficiently 
manage a large amount of persistent, reli¬ 
able, and shared data and to provide de¬ 
clarative primitives for data access and 
manipulation (that is, a query language). 

Query languages and 
query processing 

Query languages are important to 
DBMSs. A query language lets the user 
retrieve data by specifying conditions on 
the data contents. The major advantages of 
a query language are its high-levelness, 
declarativeness, efficiency, and applica¬ 
tion independence. 8 

In relational DBMSs, the query language 
provides the only means to access data. 
OODBMSs usually provide two ways to 
access data. The first is navigational, based 
on OIDs. Given an OID, the system can 
directly access the referenced object. This 
lets the application navigate through objects 
by following object references. 

The second access type is based on a 
query language, as in relational DBMSs. 
The two means of access are often com¬ 
plementary. A query selects a set of objects. 
The retrieved objects and their components 
are then accessed by using navigational 
capabilities. 

In general, object-oriented query lan¬ 
guages are similar to relational ones; often, 
the former are defined as an evolution of 
the latter. Moreover, nested relational lan¬ 
guages have many similarities with object- 
oriented query languages. 


However, there are some differences 
between relational and object-oriented 
query languages. The following section 
discusses some characteristics of object- 
oriented query languages. 

A first characteristic concerns the notion 
of equality. As we mentioned before, dif¬ 
ferent types of equality among objects can 
be defined. The type of equality used is 
important. It determines how operations 
like union, difference, intersection, and 
duplicate elimination are performed. 

Most object-oriented query languages 
include identity equality. Therefore, when 
complex objects are compared, their OIDs 
are compared. Other languages, such as 
those in Bertino et al., 9 provide both types 
of equality. 

A second characteristic concerns ag¬ 
gregation hierarchy. An important re¬ 
quirement is ease of navigation through 
object structures to impose conditions on 
the object’s nested attributes. Consider the 
query: 

Retrieve all teams with a Budget 
greater than $50,000 and supported 
by a Company located in Turin 

In relational calculus-like language, this 
query could be expressed as follows: 

{v I (3 w) (3 g) (3 i ) (Team(w) AND 
Company(g) AND Address(i) AND w 
= v AND w.Budget > $50,000 AND 
w.Industrial sponsor = g AND 
g .Location = i AND /.City =‘Turin’)}. 

The query requires the introduction of 
two variables, g and Z, and two join predi¬ 
cates to impose a restriction on a nested 
attribute of the target class. To simplify the 
formulation of conditions on nested at¬ 
tributes, query languages often include some 
form of path expressions. A path expression 
specifies an implicit join between an object 
and a component object. 

Therefore, in object-oriented languages, 
it is vital to distinguish between the implic¬ 
it join, derived from the hierarchical nest¬ 
ing of objects, and the explicit join, which 
is similar to the relational join where two 
objects are explicitly compared by using 
either the value or the identity equality. 

The previous query can now be expressed 
more concisely: 

{v I (3 w) (Team(w) AND w = v AND 
w.Budget > $50,000 AND 
w.Industrial sponsor.Location.City 
= ‘Turin’)}. 
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A predicate on a nested attribute of an 
object is called a nested predicate. Path 
expressions don’t add expressive power to 
the language, since it is possible to express 
semantics by using additional variables 
and explicit joins. 

However, path expressions are useful in 
increasing the conceptual conciseness of 
the query language. A language is con¬ 
ceptually concise if it does not require the 
introduction of artificial elements — in our 
case, variables — when specifying a que¬ 
ry. These path expressions, or similar 
syntactical notations, are provided by most 
object-oriented query languages. 

Conversely, not all object-oriented query 
languages provide explicit joins. The mo¬ 
tivation for this is based on the argument 
that in relational systems joins are mostly 
used to recompose entities that were de¬ 
composed for normalization and for sup¬ 
porting relationships among entities. In an 
object-oriented data model, there is no need 
to normalize objects since this model di¬ 
rectly supports complex objects. More¬ 
over, relationships among entities are 
supported through object references; thus, 
the same function of joins as used in the 
relational model to support relationships is 
provided more naturally by path expres¬ 
sions. 

Other relevant issues are related to in¬ 
heritance hierarchies. A query on a class 
can actually apply to the class only, or to 
the class and all its subclasses. Most lan¬ 
guages provide both possibilities. For ex¬ 
ample, in Orion, 6 when the name of a class 
is specified alone, the query applies only to 
that class. If the name of the class is fol¬ 
lowed by *, the query applies to all classes 
in the inheritance hierarchy rooted at the 
class specified in the query. For example, 
the query 

Retrieve all instances of the class 
Project and all its subclasses having 
as Participant a Team supported by a 
Company located in ‘Turin’ 

is expressed as follows 

{v I (3 w)(3 u) (Projectin') AND 
Team(n) AND w = v AND u ISIN 
w.Participants AND u .Industrial 
sponsor.Location.City = ‘Turin’)). 

The * operator applied to the class Project 
denotes that the query is applied to all 
classes in the inheritance hierarchy rooted 
at Project. In the query, the set-member- 
ship operator ISIN has been used. 

Since subclasses can have their own at¬ 


tributes in addition to those inherited from 
the superclasses, expressing queries with 
alternative predicates can be useful. 

Often, two attributes in two subclasses 
are semantically similar. For example, the 
attribute Monthly wage of the class Per¬ 
manent can be considered equivalent to the 
attribute Daily wage of the class Consult¬ 
ant, once the latter is multiplied by a given 
factor. An alternative predicate applied to 
classes C,, C 2 ,.... C„ has the form (an ac¬ 
tual syntax is specified in Bertino et al. 9 ): 

if class(x) = Cx then pred, 
if classic) = C 2 then pred 2 
...if classic) = C„ then pred„. 

In the previous expression, x is a variable 
denoting an object, and class(x) is a special 
message that applied to an object returns 
the object class. An alternative predicate is 
useful when queries contain other predicates 
on the common attributes in the inheritance 
hierarchy. For example, the query 

Retrieve all Employees living in 
Rome, such that if they are permanent 
Staff, their salary is higher than 
$4,000, if they are consultants their 
daily wage is higher than $500. 

is expressed as follows (using the syntax 
defined in Bertino et al. 9 ): 

{ v I (3 w) (Employee*(w) AND v = w 
AND w. Address.-City = Rome AND 
CLASS_OF (w) = [(Permanent: 
w.Monthly Wage > $4,000) 
(Consultant: w .Daily Wage 
> $500)])}. 

Other issues concern methods used in 
queries. Methods can be used in queries as 
derived attribute methods and predicate 
methods. A derived attribute method has a 
function comparable to that of an attribute. 
An attribute stores a value, while a derived 
attribute method is a procedure computing 
a value from the attribute values of an 
object or the attribute values of other ob¬ 
jects in the database. In the latter case, 
execution of the method causes the invo¬ 
cation of methods on other objects. An 
example of a query invoking a derived 
attribute method is the following: 

Retrieve all Projects whose Target is 
database and whose Cost is greater 
than $50,000. 

Predicate methods return the logical 
constants True or False, while derived at¬ 


tribute methods return objects (that is, 
primitive values or OIDs). The value re¬ 
turned by a predicate method can then 
participate in the evaluation of the Boolean 
expression that determines the objects 
satisfying the query. 

A relevant property of the relational 
model is that the results of queries are 
relations. Therefore, queries can be com¬ 
posed; that is, the results of a query can be 
provided as input to another query. 

In general, applying the same principle 
to object-oriented queries can be rather 
expensive. In particular, if the data model 
does not support complex values, the result 
of a query must be an object — or set of 
objects — of a class that usually is not 
already defined in the database schema. In 
other words, a query can define a new 
class. 

Since queries apply to sets of objects 
(classes or collections, depending on the 
data model), they can be composed. We 
believe this approach is conceptually cor¬ 
rect. However, it imposes some performance 
penalties, since the creation of a new class 
can be rather expensive. Therefore, some 
query languages impose restrictions on 
project operations in queries. 

A common restriction is that either all 
attributes or only a single attribute is re¬ 
trieved. Under this restriction, a query re¬ 
sult is a set of objects whose class already 
exists in the database schema. 

In data models where complex values 
are supported, a common solution is to 
define the results of a query as a set of 
tuples. An attribute of a tuple contains 
either a value or the OID of an object in the 
database. That is, the tuple results have 
pointers to the database objects satisfying 
the query. These tuples are not objects, 
they are complex values. 

Another solution is to consider the results 
as a set of object instances of a general 
class that accepts all objects and whose 
methods permit only objects to be displayed 
and printed. This solution, however, makes 
it difficult to reuse the results of a query 
and to invoke other methods on the re¬ 
trieved objects. 

The characteristics of object-oriented 
query languages make query processing in 
such systems different, in certain aspects, 
from the case of relational systems. Join 
operations in relational systems are always 
executed by comparing values; this is not 
always the case in OODBMSs, where joins 
are often implicit joins along aggregation 
hierarchies and are based on identity. 

Thus, it is possible to define some spe¬ 
cific indexing techniques (see Breitl et al. 3 
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Figure 2. A query graph example. 


for a discussion). In addition, a query can 
have not only a class as its scope but an 
inheritance hierarchy as well. Finally, us¬ 
ing both attribute and predicate methods 
extends the complexity of query process¬ 
ing. The efficient execution of queries 
containing method invocations is still an 
open problem. 

The query graph concept is useful when 
discussing query strategies. A node in a 
query graph represents a class involved in 
a query. The root of the graph is the class 
target of the query. The Target is the class 
whose instances must be returned as the 
query result. 

A query graph can have several roots if 
the query language allows the explicit join 
of several classes to be returned as a query 
result. Other classes are included in the 
query if they must be traversed to evaluate 
nested predicates or if they are subclasses 
of other classes in the graph. 

Figure 2 presents an example of a query 
graph for a query that retrieves all computer 
science institutes located in Rome and with 
teams whose budget is greater than $50,000. 

This section discusses the case of single¬ 
target queries. To evaluate a query, all 
nodes in the query graph must be visited. 
Kim proposed different visiting strategies. 6 
Even if the discussion is in the framework 
of the Orion system, 6 the discussion ap¬ 
plies to the processing of several other 
query languages, since these share many 
characteristics (such as implicit joins) with 
the Orion query language. 

Strategies that can be used for visiting 
query graphs are classified as follows: 

• Forward. The first node visited is the 
root of the graph. The other nodes are 
visited in any depth-first order. Two 
possible strategies of this type for the 
example query are 

(Institute Team Address) 
(Institute Address Team) 


• Reverse. The first node visited is one 
of the leaf nodes. The search then 
continues upward in the graph. The 
root is the last node visited. Two pos¬ 
sible strategies of this type for the 
example query are 

(Team Address Institute) 
(Address Team Institute) 

• Mixed. This strategy is a combination 
of the previous two. Two possible 
strategies of this type for the example 
query are 

(Team Institute Address) 
(Address Institute Team) 

A second dimension in query strategies 
is the technique used to retrieve data from 
the classes that are visited for the evalua¬ 
tion of nested predicates. 

Kim considers two methods for retriev¬ 
ing data from a visited class. 6 The first 
method is called nested-loop and consists 
of instantiating separately each qualified 
instance of a class. The instance attributes 
are examined for qualification, if there are 
simple predicates on the instance attributes. 
If the instance qualifies, it is passed to its 
parent node (in the case of the reverse 
strategy) or to its child node (in the forward 
strategy). 

The second method is called sort-domain 
and consists of instantiating all qualified 
instances of a class at once. All the quali¬ 
fying instances are then passed to their 
parent or child node (depending on the 
strategy used). 

By combining visiting strategies with 
techniques for retrieving instances, different 
query execution strategies are obtained. 
Kim and other related papers discuss query 
execution strategies in detail. 6 The spec¬ 
trum of possible strategies is extended when 
indexing techniques are also considered. 

As we mentioned earlier, the use of 
methods in queries has several implications 
on query processing. First, the optimization 
of queries containing method invocation is 
difficult. A method is a program, so the 
estimate of a method cost and selectivity 
can be difficult, if indeed possible. 

A common strategy used in most systems 
is to restrict the set of objects as far as 
possible before applying the method. 
Therefore, predicate methods or predicates 
on attribute methods are evaluated as late 
as possible in the query execution. Howev¬ 
er, this strategy can be inefficient in sever¬ 
al cases. 

In other approaches, the user provides 


such information as input to the system. 
This type of approach has the main disad¬ 
vantage that it can be difficult for the user 
to determine this information. 

Second, methods with side effects can 
make the result of the query dependent on 
the evaluation order for the various predi¬ 
cates. Therefore, some systems don’t allow 
methods with side effects to be used in 
queries. Others don’t take any measures 
and leave the responsibility to the user. 

Forbidding the invocation of methods 
with side effects in queries can be too 
restrictive. An open issue is to determine 
under which conditions these methods can 
be invoked without making the query re¬ 
sults dependent on the query evaluation 
strategy. 


Operational aspects 

Effective support of an object-oriented 
data model requires techniques and algo¬ 
rithms traditionally used for data manage¬ 
ment to be extended and/or modified. 
Moreover, applications that are expected 
to use OODBMSs require additional 
functionalities, such as version mechanisms 
or long transactions, that are not usually 
provided by traditional DBMSs. In this 
section, we illustrate this point by discussing 
some operational aspects of data manage¬ 
ment in OODBMSs. 

Versions. In traditional DBMSs, once 
transaction updates have been committed 
and permanently installed, the previous 
values of data usually are discarded. 
However, advanced applications, especially 
design applications, require facilities to 
maintain object versions, that is, to keep 
different states of the same object. This 
requirement is inherent in applications that 
are exploratory and evolutionary. 

Versions are useful mechanisms for 
maintaining object histories, that is, to keep 
track of object evolutions during time. 
Moreover, versions can be used to provide 
different alternatives of the same object. 
This is particularly useful in design appli¬ 
cations, where different designers might 
need to explore different design choices in 
parallel. OODBMSs providing versions 
include Avance, 1 Iris, 4 and Orion. 6 

In an OODBMS, a versioned object O is 
a collection of objects that derived directly 
or indirectly from O. The fact that a version 
V,- is derived from a version Vj establishes 
a derivation relationship between the two 
version objects. The set of all versions 


42 


COMPUTER 







related by derivation relationships is a ver¬ 
sion hierarchy. 6 

Vi and Vj are first-class objects. There¬ 
fore, they have their own OIDs and can be 
directly accessed and modified. Each ver¬ 
sion is a snapshot of an object state. The 
version management mechanism maintains 
all the information necessary to connect all 
versions of an object. 

A common way to represent the version 
hierarchy is to store it in a special object, 
called the root object. This object has its 
own OID, like any other object. All version 
mechanisms provide operations for the 
management and inspection of version hi¬ 
erarchies, such as determining the prede¬ 
cessor or successors of a given version. 
Bjornerstedt and Hulten present a taxono¬ 
my of operations. 1 

A versioned object O can be referenced 
by another object by either a specific ref¬ 
erence (also called static), or a generic 
reference (called dynamic by Kim 6 ). 

In the first case, the reference is to a 
specific version of O, while in the second 
case, the reference is to the root object of 
O. When using a generic reference, the 
system has the task of determining the 
version to be returned. This is the default 
version; it is usually the last generated. 

The Iris system 4 provides a more so¬ 
phisticated mechanism to solve generic 
references to versioned objects. The 
mechanism is declarative and is based on 
the notion of context. A context is a set of 
user-defined rules triggered on the invo¬ 
cation of methods. Using those rules, a 
user can specify that if certain conditions 
are true, each time a generic reference to an 
object is found during the execution of a 
method, a given version is to be used in¬ 
stead of the default version. 

Object versions are often classified as 
stable or nonstable. 

Stable versions are considered consoli¬ 
dated enough to be used as a basis for 
branching alternatives or important enough 
to be saved as a reference point in object 
histories. In general, some restrictions are 
placed on modifications that can be executed 
on a stable version. For example, it is 
possible to delete but not modify a version 
if other versions have been derived from it. 

Updating a stable version would require 
update propagation algorithms to ensure 
that versions derived from it are properly 
updated. As Kim noted, 6 if a stable version 
needs modification, a version can be de¬ 
rived from it containing the desired changes. 

Nonstable versions are not yet consoli¬ 
dated and therefore can undergo modifi¬ 
cations. A nonstable version can change 


into a stable version on explicit user request 
(through operations such as freeze 1 or 
promote 6 ) or automatically by the system. 
For example, in Orion, 6 a nonstable ver¬ 
sion is automatically promoted by the 
system if a version is derived from it. 

In general, most version mechanisms 
don’t support version merging. That is, a 
new version is constrained to have only 
one direct predecessor. 

The Avance system 1 provides some 
limited support for version merging. 
Whenever a new version must be derived 
as a merge of several existing versions, the 
user has to indicate one main version. Only 
the main version is copied into the new 
version, while it is left to the user to access 
the other versions to be merged and extract 
relevant information from them. The sys¬ 
tem connects as direct successor the new 
version with the merged versions. There¬ 
fore, the version hierarchy becomes a 
general graph. 

Some version mechanisms support ver¬ 
sions of classes. A major application of this 
is in the support of schema evolution, since 
it is possible to first define a class and then 
modify it without losing the previous class 
definition and the instances generated from 
it. We briefly discuss versions of classes 
with schema evolution in the next section. 

Concurrency control and transactions. 

Transactions in advanced application en¬ 
vironments differ from transactions in 
traditional environments in the following 
ways: 

• Their length can be in days or weeks, 
rather than a few seconds. 

• In some cases, it is not acceptable to 
lock an object through the entire transac¬ 
tion, since the concurrency degree would 
be drastically reduced. 

• While in a traditional environment there 
is a unique valid object state at a given 
point in time, in advanced environments 
several valid states of a given object can 

• Advanced applications are character¬ 
ized by groups of users working together. 
Therefore, support for cooperative trans¬ 
actions must be provided. 

Supporting transactions with these 
characteristics requires specific concur¬ 
rency control and recovery mechanisms. 
One approach is to have a public, shared 
database and several private databases (user 
databases). 

Each user database is a single-user sys¬ 
tem with a traditional transaction mecha¬ 


nism. A single-user system still needs a 
transaction mechanism for recovery. 
Moreover, concurrency control mechanisms 
might be needed if the user is allowed to 
execute several tasks in parallel. 

When a user needs to work on an object, 
the object is extracted from the public da¬ 
tabase and transferred (only logically in 
some cases) through a check-out operation 
into the user’s private database. The mod¬ 
ified objects are copied back into the public 
database with a check-in operation. 

Much time can elapse between a check¬ 
out operation and the corresponding check¬ 
in operation. Therefore, objects in the pub¬ 
lic database are locked with long-duration 
locks. These locks are placed in secondary 
storage so that they can survive system 
crashes or shutdowns. 

However, this approach does not let a 
user share stable but incomplete objects 
with other authorized users. This would be 
desirable if two users were cooperating on 
a task. For a user to pass such objects on to 
other users in the above system, a check-in 
operation must be executed. 

Kim et al. presented a model for solving 
this problem. 15 In the proposed approach, a 
third type of database, called a semipublic 
database, is introduced in addition to the 
public and private databases. A Semipublic 
database is associated with each long 
transaction and contains all objects that are 
not yet ready to be copied back into the 
public database but are sufficiently con¬ 
solidated to be passed to other authorized 
users. 

A transaction can check an object into 
the semipublic database by using the 
downward commit primitive. The objects 
in the semipublic database can then be 
accessed from other transactions. 

When a transaction 7j checks out object 
O from the semipublic database associated 
with a transaction 7}, 7j becomes a de¬ 
scendant of Tj. When 7) terminates the 
manipulations on object O, T, can return O 
to Tj by using the upward commit primitive. 
When a transaction with no ancestors ex¬ 
ecutes an upward commit, the object is 
copied back to the public database. Trans¬ 
action Tj, in turn, can have other descen¬ 
dant transactions. A transaction hierarchy 
is thus generated. 

This approach is useful in situations 
where groups of users cooperate in complex 
tasks, since it lets the users exchange in¬ 
complete objects in a controlled way. In 
general, most OODBMSs support or plan 
to support mechanisms for long-duration 
transactions. 

Another important concept is that of a 
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hypothetical transaction that lets a user 
experiment with complex changes without 
permanently installing them at transaction 
commit. A conventional transaction with 
the abort command available at the appli¬ 
cation interface level can pr'ovide the same 
functionality. However, a conventional 
transaction would have a nonnegligible 
effect on the performance because of log 
management. In this regard, hypothetical 
transactions are more efficient. 

A mechanism for hypothetical transac¬ 
tions has been designed and implemented 
within the framework of the Orion system. 6 
Each time an object is modified during a 
hypothetical transaction, the system creates 
a copy (called a current copy) of the object. 
The original object (called a shadow copy) 
is not modified. Further accesses and up¬ 
dates to the same object from the transac¬ 
tion are executed on the current copy. 

The current copy is deleted when the 
transaction terminates, regardless of the 
transaction outcome (abort or commit). If 
several hypothetical transactions are 
working on the same objects, each trans¬ 
action receives a different current copy of 
the object. Therefore, several hypothetical 
transactions can concurrently access and 
modify the same set of objects. 

The only restriction imposed is that the 
shadow copy be locked in shared mode. 
This prevents a normal transaction from 
modifying an object accessed by hypo¬ 
thetical transactions, thereby causing these 
transactions to read inconsistent data. 

Most OODBMSs use locking mecha¬ 
nisms for concurrency control. In Orion, 
the locking mechanism has been extended 
to account for some requirements derived 
from the object-oriented data model. 6 For 
example, one extension concerns inheri¬ 
tance hierarchies, since a class inherits at¬ 
tributes and methods from the superclasses. 

Therefore, when a user accesses a class 
or the instances of a class, the system locks 
the definitions of all superclasses to avoid 
schema changes that would propagate to 
the accessed class. A second extension 
concerns composite objects considered 
locking units. A special protocol lets the 
system lock a composite object and all its 
components without explicitly locking all 
the components. 

The Gemstone system supports an opti¬ 
mistic concurrency control mechanism, in 
addition to the locking used for pessimistic 
concurrency control. A transaction can 
access data in both the pessimistic and the 
optimistic modes. 

When a transaction T accesses an object 
using the optimistic protocol, T can be 


The authorization 
subsystem is a basic 
component of any DBMS. 
The authorization model, 
in particular, must be 
consistent with the data 
model provided by the 
system. 


aborted at commit time. This situation hap¬ 
pens if T has read or modified data that 
have been modified by another transaction 
that has executed the commit before T. 
Because of locking, this situation does not 
arise if T uses the pessimistic protocol. 

The optimistic protocol can be easily 
supported in Gemstone, since the recovery 
mechanism used by the system is based on 
the shadow pages mechanism. This mech¬ 
anism is based on maintaining two-page 
tables during the life of a transaction, called 
the current page table and the shadow page 
table. When the transaction starts, both 
page tables are identical. 

The shadow page table never changes 
during execution of the transaction. The 
current page table locates the page addresses 
on disks. The first time a page must be 
modified by the transaction, a copy of the 
page is made and the updates are made on 
the copy. The current page table is modi¬ 
fied to contain the address of the copy. All 
further updates are performed on the copy. 

If the transaction commits, the shadow 
page table is discarded and the current 
table becomes the new page table. If the 
transaction aborts, the current page table is 
discarded. In general, the optimistic protocol 
applies for read-only transactions. 

The transaction receives a consistent copy 
of the data, executes the read operations, 
and, since it does not execute modifications, 
does not conflict with other transactions. 
The integration of the two mechanisms is 
described in Breitl et al. 3 

Finally, for recovery purposes, some 
systems use the log mechanism, while 
others, like Gemstone, use the shadow 
pages. In general, the log-based approach 
is considered more efficient and preserves 
the physical contiguity of data. However, 


this mechanism is inefficient for multime¬ 
dia data, such as image and voice. Log 
mechanisms require before and after data 
images to be saved. 

In the case of multimedia data, a large 
amount of information must be stored. 
Therefore, acommon solution is to integrate 
the log mechanism used for normal data 
with the shadow pages mechanism used for 
multimedia data. This is the approach used 
in the Orion system. 

Authorization. The authorization sub¬ 
system is a basic component of any DBMS. 
The authorization model, in particular, must 
be consistent with the data model provided 
by the system. 

Authorization models have been defined 
mainly in the framework of the relational 
model. Those models usually assume that 
the relation, or the attribute, is the authori¬ 
zation unit. In some cases, a view mecha¬ 
nism supports authorization on subsets of a 
relation’s tuples. 

In OODBMSs, the object is the mini¬ 
mum granularity level that must be sup¬ 
ported. The object represents the logical 
access unit, since the user can directly 
access a single object. In addition, an object- 
oriented data model must account for 
additional aspects, such as inheritance hier¬ 
archies, versions, and composite objects. 

Definition of an authorization model 
satisfying the previous requirements is 
complex. Its implementation is crucial be¬ 
cause of the impact that authorization 
checkings can have on performance. 

An object-oriented authorization model 
has been defined in the Orion system 
framework. 6 Other systems implement less 
sophisticated models or have no authori¬ 
zation mechanisms at all. 

For example, in Gemstone, the unit of 
authorization is the segment. Each user 
owns at least one segment. All objects 
created by a user are stored in the segment 
owned by the user. A user can grant read or 
write authorization on his or her own seg¬ 
ments to other users. An authorization on a 
segment implies the same authorization on 
all objects contained in the segment. 
Therefore, the authorization granularity 
provided is rather coarse. 

In the model defined for Orion, 6 objects 
are organized with respect to the authori¬ 
zation in a granularity hierarchy, which 
defines how objects are organized in terms 
of other objects. Given an object O, the 
hierarchy defines the composition of O in 
terms of objects at a lower level than O. 

Figure 3 presents an example of granu¬ 
larity hierarchy. Granting an authorization 
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right for any object at any hierarchy level is 
possible. For example, it is possible to 
grant an authorization on the entire data¬ 
base or on a single instance. 

A fundamental concept in the authori¬ 
zation model is represented by implicit 
authorization: Given an access right A to an 
object O for a user U, U implicitly receives 
authorization A for all objects that com¬ 
pose O. For example, if a user has received 
the Read access right for the class Project, 
the user implicitly receives the same access 
right for all instances of this class. However, 
if a user has the Read access right for a 
single instance of a class, this authorization 
does not imply that the user can read other 
instances of the same class. 

The concept of implicit authorization 
avoids the explicit granting and storage of 
all those authorizations that can be derived 
from others. In addition, it provides a cer¬ 
tain degree of efficiency in some situa¬ 
tions. For example, if a user accesses an 
instance of a class and the system deter¬ 
mines that the user is authorized to access 
the entire class, further accesses to other 
instances of the same class within the same 
transaction don’t require authorization 
checks. 

The concept of implicit authorization 
was introduced in previous authorization 
models. In the model developed for the 
Orion system, 6 this concept was extended 
with the notions of weak/strong authoriza¬ 
tion and positive/negative authorization. 

A strong authorization does not admit 
exceptions on the implicit authorizations 
derived from it. A weak authorization can 
be overridden; that is, a weak authorization 
can have exceptions that are specified by 
using positive or negative authorizations. 
For example, if a user receives a weak read 
authorization for the class Project and later 
on a negative read authorization for the ith 
instance of class Project (the instance is 
denoted as Project[i] in Figure 3), the user 
can read all instances of Project except this 
instance. Since an exception can be a weak 
authorization, it is possible to define ex¬ 
ceptions of exceptions. 

Another contribution of this authoriza¬ 
tion model is that it directly supports the 
object-oriented paradigm and, in addition, 
takes aspects such as versions and composite 
objects into account. For example, an issue 
about inheritance hierarchies is whether a 
user holding an authorization for a class 
implicitly receives the same authorizations 
for all its subclasses. 

The solution chosen is that the user does 
not implicitly receive authorizations for 
the subclasses. This choice encourages the 



Figure 3. A granularity hierarchy example. (CNR is the Italian National Re¬ 
search Council.) 


reuse of existing classes without diminish¬ 
ing privacy. In fact, a user unsure about 
data privacy would probably not define the 
class starting from another class. 

Of course, the model has a special au¬ 
thorization right that lets a user derive a 
subclass from a given class. Therefore, to 
create a subclass of a given class C, a user 
U must have the authorization to generate 
subclasses from C. The creator of C, 
however, will not implicitly receive any 
authorization on the subclasses created by 
U from class C. 

The authorization model lets the user 
treat composite objects as an authorization 
unit. For example, an authorization for the 
root of a composite object implies the same 
authorization for the component objects. If 
an object is a component of several com¬ 
posite objects, as in the extended model 
defined for the Orion system, 6 a user can 
receive several implicit authorizations for 
this object. 

Because of negative authorizations, 
conflicts can arise on implicit authorizations 
on a component object. Algorithms for 
conflict detection have been defined for 
the Orion authorization model. 

Versioned objects, like composite ob¬ 
jects, can be treated as authorization units. 
For example, an authorization on the generic 
object of a versioned object O implies the 
same authorization on all versions of O. The 
user however can adopt a finer granularity, 
since granting an access right to a specific 
version is possible in any case. Such an 
authorization implies no authorization on 
other versions of the same object. A specific 
access right lets a user derive a new version 
from a given versioned object. 


Schema evolution 


Schema evolution is not inherent in the 
object-oriented paradigm. However, the 
application environments expected to use 
an OODBMS require mechanisms to sup¬ 
port complex schema changes. 

These applications are characterized by 
the fact that schema modifications are a 
rule, rather than an exception. For example, 
the ways to classify objects and their in¬ 
terrelationships commonly evolve during 
a design application. The modification 
primitives provided by relational systems 
are limited. Moreover, the modifications 
on a relation don’t affect other relations. 

The situation is more complex in object- 
oriented systems, since the spectrum of 
possible modifications is larger due to the 
increased complexity of the model. More¬ 
over, modifications to a class can affect 
other classes. For example, if an attribute is 
removed from a class definition, the at¬ 
tribute must be removed from all subclass¬ 
es of the modified class. 

Kim presented a taxonomy of basic 
schema changes. 6 Possible modifications 
include 

• changes to the definition of a class, 
such as adding, renaming, and dropping 
an attribute or a method, and changing 
the inheritance of an attribute or a 
method; and 

• changes to the inheritance hierarchy, 
such as adding or removing a superclass 
of a class. 

Basic modifications also include opera- 
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tions for creating, renaming, and removing 
a class. Schema change operations must 
keep the database schema consistent. 
Therefore, rules insuring schema invari¬ 
ance have been defined (see Breitl et al. 3 
and Kim 6 ). 

In addition, some complex changes can 
be devised. They are complex because they 
can be implemented by using the basic mod¬ 
ification primitives. Complex changes include 

• Merging two or more classes into their 
superclass. This is possible if the merged 
classes have the same attributes and meth¬ 
ods as their superclasses. 

• Generalization of two or more classes. 
This modification consists of creating a 
superclass of the given classes. The super¬ 
class contains the common attributes and 
methods of all subclasses. 

• Modifications to the aggregation hier¬ 
archy. In particular, one modification con¬ 
sists of promoting an attribute (or set of 
attributes) of a class C to a class. As an 
example, consider the class Hardware 
Project in Figure 1 and its attribute Func¬ 
tion. The domain of Function is a string. 
Suppose that more information must be 
provided about the function of a Hardware 
Project. One possibility is to create a class 
called Hardware Project Function contain¬ 
ing all the attributes needed. Then, the 
domain of attribute Function in the class 
Hardware Project is changed to the newly 
created class Hardware Project Function. 
Another modification consists of the inclu¬ 
sion of a class C in a class C', where C is 
domain of some attribute of C'. As an ex¬ 
ample, consider the classes Name and 
Employee in Figure 1. The inclusion of 
Name into Employee consists of adding the 
attributes First name and Last name to the 
class Employee and then removing the at¬ 
tribute Name from Employee and discard¬ 
ing the class Name. 

Not all complex changes can be support¬ 
ed by any system. In particular, changes 
that involve migrating instances from one 
class to another (as in the merge operation) 
might not be supported by systems where 
the OIDs contain the class identifier. In this 
case, migrating an object would invalidate 
all references to it. 

An important issue in supporting schema 
changes is how to propagate them to the 
instances of affected classes. This issue 
concerns only some types of schema changes 
— for example, the deletion of an instance 
attribute from a class. 

Other modifications, such as the deletion 
of a method, don’t affect instances. Some 


approaches have been defined for basic 
schema changes. A first approach, called 
deferred, delays the application of changes 
to instances, even indefinitely. 

Zdonik describes a proposal based on 
this approach using versions of classes. 2 A 
new version of C is generated each time a 
class C is modified. Each instance of C is 
connected to the version under which it has 
been generated. 

In addition, an exception handler is de¬ 
fined for each new class version. If an ap¬ 
plication tries to access or modify an instance 
created under a version different from that 
used by the application, an exception arises. 
This event activates the appropriate exception 
handler that in most cases propagates the 
schema change to the instance. 

The Avance system also uses an approach 
based on class version. 1 A second deferred 
approach has been defined and implement¬ 
ed as part of the Orion system. 6 In this case, 
affected instances are never modified for 
schema changes. For example, when an 
instance attribute is removed from a class, 
no actions are taken on the class instances. 
The deleted attribute is screened out when 
the instances are retrieved and presented to 
the user. 

A second approach, called immediate, 
consists of modifying the instances right 
after the change is issued. 

The advantage of the deferred approach 
is that schema change operations are not 
expensive. However, the screening can 
make instance accesses more expensive. 
Conversely, the schema change operations 
are expensive under the immediate ap¬ 
proach, while instance accesses have no 
additional cost. 

Since schema changes are frequent in 
applications supported by OODBMSs, an 
open problem is how to combine these two 
approaches to obtain a more flexible mech¬ 
anism. Furthermore, an efficient imple¬ 
mentation schema for complex changes 
should be investigated. 

An important consideration is whether 
existing methods have to be recompiled 
when schema changes are executed. For 
example, a method can invoke another 
method that has been modified. This issue 
arises in systems where type checking and 
binding are executed at compile time. 
Dynamic schema changes might not be 
supported in these systems. 

The 0 2 system 5 provided an interesting 
approach that supports two application¬ 
running modes: the development mode and 
the execution mode. The first mode is used 
during the development phase of applica- 


The application designer can interac¬ 
tively modify the schema without having 
to perform extensive recompilations, since 
features such as late binding are used under 
this mode. Increased flexibility is thus 
achieved that is important during database 
schema and application prototyping. Un¬ 
der this mode, however, performance can 
be low and errors can arise due to possible 
schema mismatches. 

End users employ the execution mode to 
run applications that are stable. To gener¬ 
ate the execution mode for a given appli¬ 
cation, the system provides a compile 
command that produces an optimized ex¬ 
ecutable code. This command has the effect 
of disallowing some modification opera¬ 
tions (such as classes, attributes, and meth¬ 
ods deletions) on the portion of the schema 
used by the compiled application. However, 
increased performance and safety are 
achieved. 


O bject-oriented database manage¬ 
ment systems overcome the tradi¬ 
tional dichotomy between data and 
operations. In traditional DBMSs, the sys¬ 
tem only stores and centralizes data. The 
high-level semantic operations on data are 
distributed among the application programs. 
By contrast, a portion of the high-level 
semantic operations in an object-oriented 
database is also centralized. Therefore, the 
application programming is simplified, 
since it often consists of invoking and as¬ 
sembling predefined semantic operations 
— the methods. 

OODBMSs also represent a point of 
convergence between the programming 
languages, which generally have no effec¬ 
tive support for persistent data, andDBMSs, 
which generally don’t have the expressive 
power of languages. Both capabilities — 
persistence and expressive power — are 
crucial for advanced applications. 

In addition, OODBMS technology ap¬ 
pears promising in the area of heteroge¬ 
neous DBMS and application integration 
(for example, see Bertino et al. 9 ). 

Even though several OODBMSs are al¬ 
ready available as products and research 
prototypes, certain open research issues 
remain. Some of the issues, such as optimi¬ 
zation of queries containing user-defined 
methods, and efficient support for schema 
changes, are discussed in this article. Other 
relevant research problems include 

• Development of formal models. An 
object-oriented data model is far more 
complex than traditional database models. 
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like the relational one. This complexity 
stems from both the structural and the be¬ 
havioral aspects of the model. In particu¬ 
lar, the behavioral aspect introduces issues 
typical of programming languages, such as 
type checking, and binding. In this sense, 
the classical notion of data modeling might 
not be completely appropriate. 

• Definition or extension of logical and 
physical database design methodologies. 
Methodologies for logical design must take 
into account not only object structures, but 
also object behaviors. Thus, software de¬ 
velopment methodology becomes relevant. 
Methodologies for physical design must 
take into account many data modeling con¬ 
structs and indexing techniques. Moreover, 
different types of object accesses, such as 
single-object access based on the object- 
identifier and access to sets of objects based 
on queries, must be supported. 

• Performance. Development of bench¬ 
marks to assess the performance of 
OODBMSs has begun. In general, because 
of object-oriented model complexity and 
additional features, such as versioning, we 
cannot expect OODBMSs to be highly ef¬ 
ficient. However, it should be noted that 
the first relational DBMSs had much the 
same problem. After several years of re¬ 
search and development, relational DBMSs 
are quite efficient. We can expect the same 
for OODBMSs. ■ 
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Reliability Modeling: 
An Overview for System 
Designers 

Andrew L. Reibman and Malathi Veeraraghavan 
AT&T Bell Laboratories 


R eliability is important in such sys¬ 
tem applications as aircraft and 
spacecraft control, telecommuni¬ 
cations, and on-line transaction process¬ 
ing. 1 System designers must evaluate alter¬ 
native architectures for these applications 
in terms of cost, performance, reliability, 
or a combination of these measures. When 
designers determine that a system is not 
reliable enough, they identify the compo¬ 
nents that can be upgraded cost-effectively 
to improve overall system reliability. Or 
they evaluate the reliability of architectur¬ 
al alternatives, such as different intercon¬ 
nection schemes or increased replication. 
Life testing — the main reliability evalua¬ 
tion technique for individual electronic 
components — can be prohibitively ex¬ 
pensive or impossible for systems, espe¬ 
cially if many design alternatives must be 
evaluated. Reliability modeling is an eco¬ 
nomical substitute. 

Reliability models can be used to 

• help set and interpret system-reliabili¬ 
ty requirements; 

• predict the reliability of different sys¬ 
tem configurations; 

• identify system-reliability weak points 
or reliability bottlenecks early in the 
product life cycle so that designers can 


Approaches for 
predicting system 
reliability include use 
of parts-count, 
combinatorial, and 
state-space models. A 
case study of a fault- 
tolerant system 
illustrates the process. 


make changes when they are less ex¬ 
pensive; and 

• determine cost-effective sparing and 
maintenance strategies. 

In this article we discuss methods for 
predicting system reliability. We also use a 
case study to illustrate reliability modeling. 

0018-9162/91 /0400-0049$01.00 © 


Reliability models in 
system design 

Reliability models are not useful in iso¬ 
lation; they are part of a larger process for 
producing a reliable system at a reasonable 
cost. To evaluate a high-level conceptual 
design, designers should formulate a pre¬ 
liminary model in which subsystems are 
black boxes. At this stage, subsystem reli¬ 
ability estimates may be only educated 
guesses. Designers can use this prelimi¬ 
nary model to generate a reliability budget 
that helps set subsystem reliability require¬ 
ments. Later, as they design subsystems, 
designers can formulate subsystem reli¬ 
ability models and use the results to update 
the high-level model. This way they can 
identify, thoroughly evaluate, and, if nec¬ 
essary, redesign subsystems that are poten¬ 
tial reliability bottlenecks. The entire pro¬ 
cess can be repeated at many different 
levels of the system design; each level of 
the model is refined as the corresponding 
level of the system design evolves. This 
iterative reliability modeling process has 
six key steps: 

(1) Choose metrics for analysis on the 
basis of system design goals. 
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Figure 1. Flowchart of the reliability modeling process. The entire process can be 
repeated at many different levels of the system design. Designers refine each lev¬ 
el of the model as the corresponding level of the system design evolves. 


(2) Build a system-reliability model. 

(3) Analyze the system model. 

(4) Refine the model until it is accurate. 

(5) Use the results to improve the de¬ 
sign and to help make design deci- 

(6) Update the model as the design 
evolves. 

Figure 1 shows these steps in a flow¬ 
chart, and the following sections present 
them in detail. 

Choosing metrics for 
analysis 

The first step in evaluating system reli¬ 
ability is to decide what metrics to analyze. 
Because the metrics should reflect system 
design goals, information to help identify 
the right metrics can come from talks with 
customers, from system requirements, and 
from careful consideration of the intended 
application. Common metrics include reli¬ 
ability, mean time to failure, availability, 
and the expected number of failures. 

• Reliability is “the probability of a sys¬ 
tem performing its purpose adequately for 
the period of time intended under the op¬ 
erating conditions encountered.” 2 System 
reliability depends on the length of time 
considered. For commercial systems, this 
time period might cover the duration of the 
warranty (months or years). For an aircraft 


flight-control computer, where failure could 
result in the loss of the aircraft, the primary 
design goal is to guarantee continuous op¬ 
eration (extremely high reliability) during 
a reasonably short mission (hours). In the 
case study we present at the end of the 
article, the desired reliability is at least 
0.999999 (1 - I (r 6 ) for a 5-hour mission. 
For spacecraft, the requirement (as a num¬ 
ber) might be much looser — for example, 
0.99 for a mission instead of0.999999. But 
mission time for spacecraft is often years 
rather than hours, so the design requirements 
are just as difficult to meet. 

• Mean time to failure is the expected 
time until a system fails. Unlike reliability, 
MTTF does not depend on a particular 
operating time. Instead, MTTF gives the 
average time that a system can be expected 
to operate without failing. MTTF is a con¬ 
venient “figure of merit” for comparing 
different system designs. However, like all 
averages, it does not convey the variability 
possible across many systems: A MTTF 
significantly longer than a given mission 
time does not mean that the system will be 
highly reliable for that mission time. Aver¬ 
ages depend on the whole system life dis¬ 
tribution. A small chance of having a long 
life can greatly increase the MTTF. Com¬ 
puting the variance of the time to failure 
increases the utility of the MTTF metric by 
suggesting how much typical systems can 
deviate from the average. 

• Availability is the probability that the 
system will be operational at a given time. 
Long-term (or steady-state) availability is 


the fraction of time the system is opera¬ 
tional over a period of time. Availability is 
often expressed as an amount of outage per 
unit of time, for example, hours per year. 
Applications where the primary concern is 
availability rather than reliability include 
repairable systems like telecommunications 
switches and commercial transaction pro¬ 
cessors. These systems are intended to pro¬ 
vide service almost continuously, although 
infrequent short outages are tolerable. A 
limitation of the availability metric is that 
it does not reflect the frequency of inter¬ 
ruptions or the maintenance required. 

• Expected number of failures indicates 
how many failures or interruptions can be 
expected in a given period of time. This 
metric helps determine how many spares 
and how much maintenance capability to 
provide. Fault tolerance at the system level 
may actually increase the number of fail¬ 
ures, because all component failures must 
be repaired, even if they do not cause 
system failure. A system-level fault-toler¬ 
ance scheme that provides high system 
availability may have more circuit packs, 
and hence more circuit pack failures and 
replacements. To simplify maintenance, 
designers need to incorporate fault toler¬ 
ance within individual line-replaceable 


Different applications impose different 
requirements on system designers, leading 
to different metrics for analysis. But de¬ 
signers can use the same basic types of 
models for reliability, availability, and 
similar metrics. More complicated models 
for performability combine reliability and 
performance metrics for evaluating real¬ 
time systems and gracefully degradable 
fault-tolerant systems. 3,4 

Creating a system- 
reliability model 

The language of system design and the 
language of reliability modeling are not the 
same. Given a system description, design¬ 
ers must extract the important features of 
the design to build a useful reliability model 
of the system. In this section, we discuss 
different types of reliability models and 
illustrate their use with several examples. 

An iterative, hierarchical approach to 
modeling conveniently parallels the hier¬ 
archical design process. Designers can use 
different types of reliability models or re¬ 
liability information in different parts of 
the design. For example, a simple parts- 
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count model can model individual circuit 
packs, while a more complicated state dia¬ 
gram represents system-level failure and 
repair processes. Initially, when designs 
are informal, models can be simple and 
need only roughly capture the main sys¬ 
tem-reliability trends. As the system design 
evolves, more detailed models represent 
the system more accurately. 

In addition to a hierarchical approach, 
software tools such as reliability model 
specification languages and reliability 
modeling packages can simplify model 
building and reduce the chance of error. 5 
Model generation can be manual or auto¬ 
mated. While people build the models, 
powerful specification languages can sim¬ 
plify model specification. Software can 
automate specification, directly translat¬ 
ing a formal system specification into a 
system-reliability model. 6 For example, the 
circuit pack descriptions from a CAD system 
can be directly converted to reliability 
models for the circuit pack, avoiding errors 
in model building. 

Once designers have specified the mod¬ 
el, they need to analyze it. Early in the 
process, they make many simplifying as¬ 
sumptions. In the later design stages, a 
reliability modeling software package can 
analyze more complicated models. 6 

Several factors can affect fault-tolerant 
system reliability. Their effects are difficult 
both to measure and to model. 

• Coverage. If a fault occurs in a compo¬ 
nent or subsystem, can the system recon¬ 
figure or mask the fault so that no system 
outage occurs? Fault coverage, the proba¬ 
bility that a system can successfully handle 
a fault, 7 estimates the effectiveness of 
masking and reconfiguration. Causes of 
imperfect coverage include dependency 
between components, inability to detect 
component faults, near-coincident faults 
(two or more faults occurring within a 
short time period and overloading the re¬ 
covery process), and bugs in reconfigura¬ 
tion software. Because effective fault han¬ 
dling is crucial in using redundancy to 
improve reliability, designers must ana¬ 
lyze the reconfiguration process carefully. 7 

• Dependency. Dependent primary 
components and backups diminish the reli¬ 
ability improvement achieved by adding 
extra hardware. For example, two proces¬ 
sors sharing a power supply both crash if 
the power supply fails. To help ensure 
independence, designers can replicate a 
complete unit, including external interfac¬ 
es and power supplies. 

For simplicity, most reliability models 


assume that individual subsystems fail in¬ 
dependently; thus, designers can analyze 
independent subsystems separately and 
combine the results. If subsystems are de¬ 
pendent, decomposing a model can result 
in a significant overestimation of system 
reliability. A more accurate model that 
represents the dependent failures cannot 
be decomposed, so it is harder to analyze. 

• Stiffness. Failures occur slowly (over 
thousands of hours), while automatic re¬ 
configurations occur rapidly (possibly in 
milliseconds). The presence of two drasti¬ 
cally different event rates in a model is 
called stiffness. Stiffness makes simula¬ 
tion and numerical model evaluation dif¬ 
ficult and expensive. 

In typical reliability modeling applica¬ 
tions, designers handle these factors with 
bounds or simple approximations. When 
modeling ultrareliable fault-tolerant sys¬ 
tems, they must use special techniques for 
dealing with imperfect coverage, depen¬ 
dency, and stiffness. 8 

Types of models. Three common types 
of reliability models are parts-count mod¬ 
els, combinatorial models, and state-space 
models 1>2,9 : 

• Parts-count models. A parts-count 
model can give a “first cut” reliability 
estimate for most systems. This approach 
assumes that the failure of any component 
or subsystem causes a system failure. The 
system failure rate is the sum of all the 
component failure rates. Simple parts-count 
models usually provide an adequate reli¬ 
ability estimate for individual circuit packs 
or small computers. However, if the sys¬ 
tem can tolerate some component failures, 
parts-count estimates are overly conserva¬ 
tive. If designers introduce fault-tolerant 
features into a system, they need other 
reliability models. 

• Combinatorial models. Combinatorial 
models, including/ait/f trees, success trees, 
and reliability block diagrams, are exten¬ 
sions of parts-count models. These models 
can represent simple redundant systems 
with perfect switching. Unfortunately, 
combinatorial models do not represent in 
detail many aspects of fault-tolerant sys¬ 
tems that can strongly affect system reli¬ 
ability, including repair, reconfiguration, 
and fault coverage. 

• State-space models. Because combi¬ 
natorial models cannot easily capture many 
important features of fault-tolerant sys¬ 
tems, designers often use such state-space 
models as Markov chains. In the model, 



Figure 2. Success tree for a series sys¬ 
tem. The basic events represent the 
computers Cl and C2 and power sup¬ 
ply P functioning. The system fails if 
either computer or the power supply 
fails. 


each possible combination of “up” and 
“down” components has a corresponding 
state. Evaluating the model using simula¬ 
tion or numerical algorithms yields esti¬ 
mates of the system’s probability of being 
in each state. Once designers evaluate the 
model, they can estimate different reliabil¬ 
ity metrics easily. For example, MTTF is 
the average time until a down state is 
reached, while availability is estimated by 
comparing the amount of time spent in up 
states with the amount of time spent in 
down states. 

Simple example. In this section, we use 
a sequence of simple models to illustrate 
some types of system behavior easily rep¬ 
resented by different kinds of reliability 
models. As a common example, we use a 
system with two computers and a shared 
power supply. We assume that the neces¬ 
sary reliability information for the sub¬ 
systems is available from field data or a 
parts-count model. 

Success tree model. If both computers 
are needed for acceptable system opera¬ 
tion, then the failure of the power supply of 
either computer will cause a system fail¬ 
ure. As Figure 2 shows, this is a series 
system represented by an AND gate in a 
success tree. The top event in a success tree 
is “system operational.” (The top event in 
a fault tree is “system failure.”) All compo¬ 
nents of an AND gate must work if the 
system it represents is to work. Circles 
represent individual components; The cir¬ 
cles with C represent computers, and the 
circle with a P represents the power supply. 

Suppose R c is the reliability of a com¬ 
puter subsystem and R p is the reliability of 
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system. The system requires the power 
supply and one computer to function. 
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Figure 4. Markov reliability model of a 
two-processor system. State 2 repre¬ 
sents two processors operating, state 1 
represents one processor operating, 
and state 0 represents no processors 
operating. The processor failure rate is 
X, and the processor repair rate is p. 


the power supply. The overall system-reli¬ 
ability estimate is R 2 R p , if the components 
fail independently. Thus, adding an extra 
component to a series system decreases 
reliability. 

If the system can function with one com¬ 
puter down, the computers are in parallel. 
As Figure 3 shows, the success tree now 
includes an OR gate. If any subsystem of a 
system represented by an OR gate works, 
then the system works. The system reli¬ 
ability is [1 - (1 - R c ) 2 ]R p . Adding a re¬ 
dundant computer to the parallel system 
modeled in Figure 3 increases reliability. 

A simple sensitivity analysis with these 
models points out several important facts. 
Typical commercial computer failure rates 
are around 10~ 5 failures per hour, with an 
average repair time of about four hours. 
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Figure 5. Markov reliability model of a 
two-processor system with imperfect 
coverage. The arc from state 2 to state 
0 represents a single processor failure 
for which the fault-tolerance features 
cannot successfully reconfigure. 


This gives a steady-state availability of 
approximately 0.9996 for individual com¬ 
puters. In the series system, unless the 
power supply is much less reliable than the 
computers, it is probably most cost-effec¬ 
tive to try to improve the computers’ avail¬ 
ability. In the parallel system, the probabil¬ 
ity of both computers being unavailable 
simultaneously is approximately 10 -7 . Here 
it is almost pointless to try to improve 
individual processor availability, unless 
the power supply is far more reliable than 
the processors. If the power supply has 
about the same failure rate as a processor, 
designers should investigate a fault-tolerant 
or redundant power supply to eliminate the 
power supply as a single point of failure. 

These two simple models give a rough 
idea of the reliability of parallel and series 
designs. They capture the basic difference 
between a fault-tolerant system and one 
with no fault-tolerance capabilities. At early 
development stages, such simple models 
are often adequate for high-level design 
decisions. But, if designers need more de¬ 
tail, these simple combinatorial models 
cannot capture many aspects of real fault- 
tolerant system behavior, like coverage 
and dependence. 

Markov chain reliability model. Markov 
chains are more powerful than reliability 
block diagrams, but they are also more 
complex. Figure 4 shows a simple Markov 
chain model corresponding to the comput¬ 
er portion of the reliability block diagrams 
in Figures 2 and 3. Circles represent the 
different states of the system. State 2 rep¬ 
resents two computers operating, state 1 
represents one computer operating, and 
state 0 represents no computers operating. 


In both the series and parallel systems, 
state 2 is an operational state, and state 0 a 
down state. State 1 is a down state in the 
series system and an operational state in 
the parallel system. 

Arcs represent transitions between states. 
Constants on the arcs are the transition rates 
between states. For example, the arcs go¬ 
ing right represent computer failures, with 
X the failure rate of a single computer. The 
arcs going left represent repairs, with |i as 
the repair rate for an individual computer. 

We have assumed that the second pro¬ 
cessor can fail even when the system is 
down. We could change this assumption 
by deleting the transition from state 1 to 
state 0. A combinatorial model (fault tree, 
success tree, or reliability block diagram) 
cannot capture this type of state-dependent 
behavior. 

Another example of state-dependent 
behavior is shared repair facilities. When 
repair is included, combinatorial models 
assume that there is an independent repair 
facility for each component. This would 
mean that the rate from state 0 to state 1 is 
twice the rate from state 1 to state 2. Such 
an assumption may not be realistic. In a 
model of a two-computer system with only 
a single repair facility, the rate from state 0 
to state 1 would be the same as the rate 
from state 1 to state 2. Designers can com¬ 
pare these two models to make decisions 
about the appropriate maintenance policy. 

Markov chain reliability model with 
imperfect coverage. A second factor that 
models of fault-tolerant systems need to 
include is imperfect coverage. The model 
in Figure 4 assumes that the system can 
always recover successfully from a single 
computer failure. A real system’s fault- 
tolerance features will not cover all fail¬ 
ures. Some failures may not be properly 
detected, while others may affect both 
computers. Figure 5 shows a simple addi¬ 
tion to the model in Figure 4 that can 
capture the effect of imperfect coverage. 
The arc directly from state 2 to state 0 
represents a single computer failure for 
which the fault-tolerance features cannot 
successfully reconfigure the system. The 
constant c is the fault coverage and denotes 
the probability that the system will recover 
successfully from a single computer failure. 

Using the parameters from the previous 
subsection and the model in Figure 5, we 
can examine the effect of imperfect cover¬ 
age. When fault coverage is 99 percent, 
system outage from coverage failure is 
around 10 -5 . This is two orders of magni¬ 
tude larger than the outage from having 
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both computers down. In a fault-tolerant 
system, trying to improve coverage is of¬ 
ten more cost-effective than reducing fail¬ 
ure rates. Techniques to improve coverage 
include better fault detection and faster 
reconfiguration. 

In a real system design, simple models 
can point out important facts about system 
reliability. In our example, they highlight 
the importance of single points of failure 
and imperfect coverage. As a design 
progresses, designers can refine and add 
detail to the models. For example, a more 
detailed model of reconfiguration when a 
fault occurs should yield a better estimate 
of the coverage. 

Refining the model 

Given a system model, designers must 
decide whether it is accurate enough for 
design decisions. If not, they need to refine 
it. Identifying the potential sources of error 
is the first step in evaluating a model’s 
accuracy and suggests how to improve a 
model. There are several common errors: 

• Modeling errors are inaccuracies 
caused by the simplifying assumptions that 
underlie the model. Typical modeling er¬ 
rors include assuming independence or an 
incorrect failure time distribution. 

• Specification errors are accidental 
structural errors in the model, like missing 
or extra states. 

• Parametric errors are errors or uncer¬ 
tainty in the model parameters, like failure 
and repair rates. Designers obtain parame¬ 
ters from such imperfect sources as tests 
and field data. Early in the design cycle, 
some input parameters may be nothing 
more than educated guesses. 

• Solution errors are produced by ap¬ 
proximate solution techniques, numerical 
procedures, and simulation. Most solution 
algorithms can be extended to give solu¬ 
tion error estimates. Designers can reduce 
these errors with careful use of the special 
numerical algorithms and simulation. But 
more accurate solutions usually require 
more computational effort. 

Good numerical software should auto¬ 
matically provide error estimates that help 
control solution error. Automating model 
specification minimizes specification er¬ 
rors. Designers can reduce parametric er¬ 
rors by improving the quality of the data (for 
example, component reliability information) 
that they use to formulate the model. Sever¬ 
al other good practices minimize errors: 



In a real system design, 
simple models can 
point out important 
facts about system 
reliability. 


• Identify assumptions. Designers should 
explicitly identify the simplifying assump¬ 
tions they use in the model. As the system 
design changes, the validity of assump¬ 
tions may change, and the model may need 
revision. Also, if the model proves to be 
inaccurate, the list of assumptions is a 
convenient place to look for ways to im¬ 
prove its accuracy. 

• Document information sources. De¬ 
signers should thoroughly document and 
review reliability information sources to 
determine how trustworthy the informa¬ 
tion is. Such documentation shows where 
to begin looking if designers need more 
accurate information. For example, common 
sources of information on circuit packs are 
field data, predictions, and requirements. 
Field data tends to be the most accurate, 
assuming the data has been properly col¬ 
lected and analyzed. But field data is ex¬ 
pensive to collect and is not available for 
newly designed components. Circuit pack 
reliability predictions are less accurate than 
field data. Although they may be off by as 
much as a factor of two or three, they are 
generally conservative — they tend to un¬ 
derestimate reliability. For subsystems that 
have not yet been designed, sources of 
rough estimates include requirements, in¬ 
formation available on earlier versions of 
the same component, and information on 
similar products. 

• Build conservative and optimistic 
models. A model is based on many simpli¬ 
fying assumptions. Bounding the error 
caused by approximations increases confi¬ 
dence in a simple model. Conservative 
assumptions decrease the estimated reli¬ 
ability. For example, increasing estimated 
component failure rates is conservative. 
Another common conservative assumption 
is that any multiple component failure in a 
fault-tolerant system causes system fail¬ 
ure. Optimistic assumptions increase the 
estimated reliability. For example, assum¬ 
ing that no multiple component failures 


will occur is an optimistic assumption. 
Designers can build two models, one based 
entirely on conservative assumptions and 
the other entirely on optimistic assumptions. 
The estimated system reliability falls be¬ 
tween the two. This approach is typically 
applied to bound the effect of errors in the 
model parameters. Designers use optimistic 
and conservative system models based on 
upper and lower bounds on model param- 

• Conduct sensitivity analysis. Sensitivity 
analysis determines how changes in model 
parameters (for example, component fail¬ 
ure rates) or other model assumptions af¬ 
fect the overall system reliability. 10 If the 
model is sensitive to a particular parame¬ 
ter, the parameter needs further investiga¬ 
tion because even a small error could sig¬ 
nificantly change the model results. 
Sensitive parameters may also indicate weak 
links in the design — components that are 
system-reliability bottlenecks. Upgrading 
them might enhance overall system reli¬ 
ability considerably. 

• Review models. Having both design and 
modeling experts review a model can help 
identify errors and hidden assumptions that 
may affect the results. Reviews can be 
informal or formal, similar to software 
design walk-throughs. The main goal is not 
to eliminate all errors. Models only ap¬ 
proximate the system. The goal is to ensure 
that the model adequately captures impor¬ 
tant aspects of system behavior. 

Several iterations may be needed to pro¬ 
duce a model that captures the important 
elements of system behavior. When the 
model is acceptable, designers can use it 
for design decisions. 

Case study 

To help illustrate the modeling process, 
in this section we evaluate a high-level 
design of a hypothetical example based on 
the Advanced Information Processing 
System I/O network, 11 a system for future 
aircraft applications. We first describe the 
preliminary AIPS system design. Follow¬ 
ing the steps in the flowchart in Figure 1, 
we choose a metric for analysis and build 
some simple combinatorial models to bound 
the reliability of the design. Next we build 
a more refined model, using a Markov 
chain. Then we use the models to evaluate 
a design improvement. 

System description. Figure 6 shows a 
preliminary design of the AIPS I/O net- 
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Table 1. Failure rates of AIPS components. 


Component 

Failure Rate 

Value (failures/hour) 

Processor 

X P 

1.0 x lO" 4 

Node with sensor/actuator 

X N 

6.0 x lO’ 6 



Figure 6. Design of the AIPS I/O net¬ 
work. Rectangles represent the three 
processors. Circles represent the nodes 
with their attached sensors or actua¬ 
tors. Nodes in corresponding positions 
of different rings are attached to sen¬ 
sors or actuators that have the same 
function. 


work. The system consists of three identi¬ 
cal subsystems. Each subsystem consists 
of five nodes interconnected in a ring and 
a processor connected to the ring by two 
links. Each node in turn is attached to a 
sensor or an actuator. Nodes in corre¬ 
sponding positions of different rings have 


the same function: They collect the same 
input information via sensors or pass the 
output information to the same type of 
actuator. For example, in Figure 6, nodes 
A1, A2, and A3 are all attached to temper¬ 
ature sensors. 

A voting scheme determines each input 
and output value. If two out of three sen¬ 
sors or actuators of the same type fail, the 
system is declared nonfunctional. If a node 
fails, the sensor or actuator attached to it is 
unavailable. Similarly, if a processor fails, 
the entire ring attached to it is unavailable. 
A careful evaluation will help determine 
whether this redundancy scheme meets the 
system’s stringent reliability requirements. 

Choice of metrics. The AIPS network is 
designed for use in highly reliable flight- 
control systems. Its reliability requirement 
is 0.999999 (1-10~ 6 ) for a 5-hour mission. 


Our analysis focuses on finding the proba¬ 
bility that the AIPS I/O network will re¬ 
main functional for a 5-hour mission. 

Preliminary model. In our first step in 
modeling the system, we use parts counts 
to compute the estimated component fail¬ 
ure rates listed in Table 1. Device failure 
rates and failure rate multipliers are avail¬ 
able from military-standards tables. We 
combine these failure rates to obtain the 
failure rates of system components. 1 Al¬ 
though these estimates are not as accurate 
as field measurements, they are adequate 
for our preliminary reliability model. 

Next we list the modeling assumptions. 
We made some of these assumptions to 
simplify the example for presentation here. 
In an actual analysis, designers would re¬ 
fine these assumptions to get more accu¬ 
rate results. In particular, they would carry 
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out a detailed analysis of coverage and 
component dependencies. Here are our as¬ 
sumptions: 

• Components have exponential time- 
to-failure distributions, with the constant 
failure rates given in Table 1. 

• All components fail independently. 

• There is no repair during the 5-hour 
mission. 

• The voting mechanism is completely 
reliable. 

• All links are perfectly reliable. A more 
detailed system analysis showed the link 
failure rate to be an order of magnitude 
smaller than the node failure rate. Because 
at least three component failures are need¬ 
ed for system failure (involving two links 
and a node or four links), this failure rate 
allows us to assume perfect links without 
significantly affecting our results. (This 
assumption can be one of the first that we 
relax during model refinement.) 

• Three different combinations of com¬ 
ponent failures cause a system failure. The 
system fails when two or three processors 
fail, when two nodes in the same position 
on two different rings fail, or when any 
node fails in a ring and a processor control¬ 
ling another ring fails. 

We want to build a simple combinatorial 
model for the system. However, represent¬ 
ing the system precisely with a combinato¬ 
rial model is difficult. Instead, we build 
two simplified models — one conservative 
and one optimistic. The estimated system 
reliability lies between the results obtained 
from the two simplified models. 

In the conservative model, we assume 
that failure of any processor or node in a 
ring will cause ring failure. The failure of 
two of the three rings causes a system 
failure. Figure 7 shows the success tree for 
this conservative model. A basic event is a 
success if the corresponding component is 
functional. For example, the basic event PI 
is a success if processor 1 is functional. 
When a component fails, its corresponding 
basic event also fails. Failure of any pro¬ 
cessor or node in a ring leads to a failure on 
the corresponding input to the AND gate 
representing that ring. The outputs of the 
three AND gates (corresponding to the 
three rings) are input to a 2/3 AND gate. 
This gate represents a two-out-of-three 
system that is operational if at least two of 
its three subsystems are operational. 

The model is conservative because all 
combinations of component failures that 
cause a failure in the real system also cause 
a failure in the model. In addition, the 


model includes some combinations of 
component failures that are not failure events 
in the real system. Solving the conserva¬ 
tive model yields an unreliability estimate 
for a 5-hour mission of 1.3 x 10 -6 . 

The optimistic model ignores the system 
topology and assumes that any working 
component can be used. The system fails if 
any two components of the same type fail. 
Figure 8 gives the success tree for this 
optimistic model. Every combination of 
component failures that causes a failure in 
the model also causes a failure in the real 
system. Some failures in the real system 
may not be included as failures in the 
model. Solving the optimistic model yields 
an unreliability estimate for a 5-hour mis¬ 
sion of 7.6 x 10“ 7 . 

The results from these two models sug¬ 
gest that the system architecture has a chance 
of meeting the 5-hour mission unreliability 
goal of 10 -6 . However, the conservative 
reliability estimate does not meet the re¬ 
quirement, so we refine the reliability model. 

Model refinement. As a refinement, we 
build the Markov model for the system 
shown in Figure 9 on the next page. To 
simplify the model, we truncate it to include 
only states with at most three component 
faults. When we solve the model, we will 
bound the error introduced by this trunca¬ 
tion. Table 2, on the next page, lists the 
states of the model. In the table, F states 
represent component failures that do not 
cause system failure, while SF states repre¬ 
sent component failures that cause system 
failure. 

The total transition rate out of state G is 


1 5X n + 3A, P . This is the total component 
failure rate in a system with a full comple¬ 
ment of working components. A processor 
failure (rate 3 A, P ) causes a transition to state 
F P . A node failure (rate 15A, N ) causes a 
transition to state F N . We compute the 
other transition rates similarly. A node 
failure and a processor failure cause a sys¬ 
tem failure if they occur in two different 
rings (state SF NP ). If they are on the same 
ring, the system is functional (state F NP ). 

In this model, state 3F is an aggregate 
state , with all the different combinations of 
three or more component faults lumped 
together. Some combinations result in sys¬ 
tem failure and some do not. We can get a 
lower bound on system reliability by as¬ 
suming that state 3F is a failed state, and an 
upper bound on system reliability by as¬ 
suming state 3F is operational. Solving the 
two versions of the Markov model in Fig¬ 
ure 9 for a mission time of 5 hours yields an 
unreliability estimate of 1.212 X 10 -6 for 
both models; the difference is less than 
10~ 9 . Because the bounds are close, we 
know that truncating the model (ignoring 
the possibility of more than two faults) 
does not significantly affect the reliability 
estimate. This means that almost all sys¬ 
tem outage is caused by double faults. 
Generally, the probability of k reliable 
components failing in a short interval is 
significantly less than the probability of 
k - 1 components failing. 

Unfortunately, the result suggests that 
the system will not meet the reliability 
requirement. Before we redesign the sys¬ 
tem, we refine the model to confirm that an 
expensive redesign is really necessary and 



Figure 8. Optimistic success tree for AIPS. The system fails only if two compo¬ 
nents of the same type fail. 
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Figure 9. Markov model of the AIPS 
I/O network design. Table 2 lists the 
states of the model. The processor fail¬ 
ure rate is A. P , and the node failure rate 

is/t N . 


to gain insight into cost-effective system 
refinements. In a more complete analysis 
we could build additional models to show 
the effect of these assumptions on estimat¬ 
ed system reliability. For example, a para¬ 


metric sensitivity analy¬ 
sis would show the effect 
of changing parameter 
values. 10 Or we could 
model an imperfect vot¬ 
ing mechanism using a 
coverage model. 8 (Dug¬ 
an et al. present a more 
detailed analysis of the 
AIPS system. 12 ) 

For illustration, we 
assume that further mod¬ 
el refinement confirms 
that the estimated system 
unreliability for a 5-hour 
mission does not meet the 
system requirements. 
Now we consider system 
design improvements. 

System design re¬ 
finement. The first step in refining the 
system design is to identify the main causes 
of system failure, the system’s reliability 
bottlenecks. Table 3 shows more detailed 
results from the reliability model in the 
previous subsection. The main causes of 
system failure are the failure of two pro¬ 
cessors (SF 2 p) and the failure of a proces¬ 
sor and a node on different rings (SF NP ). We 
need to increase the processors’ reliability 
or improve the system’s ability to tolerate 
processor failures. 

Increasing redundancy is a common ap¬ 



Figure 10. Modified design of the AIPS 
I/O network. Each processor is con¬ 
nected to two different rings. 


proach to improving reliability. For exam¬ 
ple, we could add spare processors or add 
redundancy inside the processors to im¬ 
prove their reliability. Even though this 
redundancy might significantly improve 
system reliability, AIPS cost and perfor¬ 
mance considerations do not permit in¬ 
creasing redundancy. Therefore, we look 
for ways to decrease the number of failure 
modes in the system without increasing the 
number of components. 

Figure 10 shows the design topology 
changed to the cross-strap design suggest¬ 
ed by Lala. 11 Each processor communi¬ 
cates with two different rings, eliminating 
the most common cause of system failure: 
the failure of a processor and a node in 
different rings. In addition, because a pro¬ 
cessor can control two rings simultaneously, 
the system might be able to function even 
if two processors fail. Here the only se¬ 
quence of two component failures that 
causes a system failure is two node failures 
in corresponding positions on different 
rings. 

Figure 11 shows a Markov model for the 
cross-strap design. The model has two cas¬ 
es, depending on whether two processor 
faults can be tolerated. 

In case 1, two processor faults cause a 
system failure. Here the state SF 2P is a 
system failure state, and the dotted transi¬ 
tion from state SF 2P to state 3F is ignored. 
This is the conservative case. Solving the 
Markov model for this case with a mission 
time of 5 hours yields an unreliability of 
between 7.62 x 10~ 7 and 7.63 x 10“ 7 , de¬ 
pending on whether the three-fault state is 
considered operational or failed. Since this 
model is conservative and the result is 
within the reliability requirement, this sys¬ 
tem design should be acceptable. Howev- 


Table 2. States of the model in Figure 9. 


State 

Failed Components 

System Failure? 

G 

None 

No 

F P 

1 processor 

No 

F n 

1 node 

No 

Fnp 

1 node and 1 processor 

No 

F 2 N 

2 nodes 

No 

sf 2P 

2 processors 

Yes 

SF 2 n 

2 nodes 

Yes 

sf np 

1 node and 1 processor 

Yes 

3F 

Any 3 components 

Aggregate of up and down states 


Table 3. Results of Markov model analysis of the AIPS cross-link configuration. 


State 

Probability at t = 5 hours 

sf 2n 

1.34 x Hr 8 

sf 2p 

7.49 x 1(T 7 

SF np 

4.49 x 1(T 7 

3F 

1.57 x 10- 10 
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er, the results are still close to the requirement, so making a more 
detailed model is worthwhile. 

Actual system operation is probably more accurately represent¬ 
ed by case 2, which gives even better results. If two processor 
faults do not cause a system failure, state SF 2 p is operational. The 
dotted transition from state SF 2 p to state 3F exists. Solving for case 
2 of the Markov model for a mission time of 5 hours yields an 
unreliability of between 1.35 x 10 -8 and 1.41 x 10~ 8 , depending on 
whether the three-fault state is considered operational or failed. 
This is well within the reliability requirement. 

T his case study illustrates the steps of reliability modeling 
and how they can be incorporated in the design cycle. 
Although the models were small and simple, the basic 
modeling process is almost identical to the one we use in large 
system development projects. 

The basic modeling strategy is iterative; models can be succes¬ 
sively refined as needed. Results from preliminary design models 
can help in negotiating system requirements. Models can identify 
weak-link subsystems, where design improvements may have a 
high payoff in improving the entire system’s reliability. For fault 
tolerance, reliability predictions can help designers pick the most 
cost-effective level of redundancy. Once the system is designed, 
reliability predictions help optimize maintenance strategies and 
determine the number of spares needed. ■ 



Figure 11. Markov model of the modified AIPS I/O network 
design. The combination of a processor and a node failure 
does not cause system failure. If the system can tolerate two 
processor failures, state SF 2P is not a system failure state 
and the dashed arc to state 3F is needed. 
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Interactive Systems: 

Bridging the Gaps Between Developers and Users 

Jonathan Grudin, Aarhus University 


T oday, user needs are recognized to 
be important in designing interac¬ 
tive computer systems, but as re¬ 
cently as 1980, they received little empha¬ 
sis. In most major systems development 
companies, the basic organizational struc¬ 
tures and development processes were 
defined in an earlier era, when the dialogue 
between computer systems and computer 
users did not have to be considered. 

This point is of more than historical 
interest; it raises some basic questions: 
Can these companies develop effective in¬ 
teractive systems? What changes would 
bring greater knowledge of users and their 
work environments into systems develop¬ 
ment? How long will it take to translate this 
new understanding into reliable, effective 
practice? 

Until 15 years ago, most computer sys¬ 
tem users were engineers and program¬ 
mers. Developers were designing systems 
for their own use or for other technically 
proficient users. They felt no need to seek 
user participation in design. Now, howev¬ 
er, computer use has spread to workplaces 
that are very unlike engineering laborato¬ 
ries. Contact with system users is required, 
but determining how direct or extensive 
this contact need be and actually achieving 
it have been surprisingly difficult. 

Toward a user focus. Early proponents 
of greater user involvement included both 
human factors specialists and systems de¬ 
velopers. An IBM usability research group 
stressed “an early focus on users” in the 


Three development 
contexts provide a 
framework for 
understanding 
interactive software 
development projects: 

competitively bid, 
commercial product, 
and in-house/custom 
development. 


1970s, and an influential 1983 paper rec¬ 
ommended that “typical users (e.g. bank 
tellers, as opposed to a ‘group of expert’ 
supervisors, industrial engineers, pro¬ 
grammers) ... become part of the design 
team from the very outset when their per¬ 
spectives can have the most influence, rather 
than using them to ‘review,’ ‘sign off on,’ 
‘agree’ to the design before it is coded.” 1 
Perhaps coincidentally, this paper appeared 
when popular books such as In Search of 
Excellence were urging industry to cater to 
the customer. A user focus was further 

0018-9162/91/0400-0059$01.00 © 1991 IEEE 


emphasized in User Centered System De¬ 
sign, 2 an influential 1986 collection of re¬ 
search papers. Also in the 1970s and 1980s, 
Europeans experimented with greater user 
involvement in systems design. In particu¬ 
lar, the Scandinavian “participatory de¬ 
sign” approach, in which users collaborate 
as full development team members, at¬ 
tracted attention (see Suchman’s review, 
“Designing with the User”). 3 

The challenge of designing better inter¬ 
active systems has not gone unnoticed in 
software engineering. Boehm observes that 
the dominant waterfall development mod¬ 
el “does not work well for many classes of 
software, particularly interactive end user 
applications.” 4 His proposal, a “spiral 
model” of software development, incorpo¬ 
rates user involvement, prototyping, and 
iterative design. Yourdon recently wrote, 
“The first, and by far the most important, 
player in the systems game is someone 
known to systems analysts as a user.” 5 

The spiral model is not yet widely used, 
and as Boehm notes, it may be difficult to 
apply in some contexts. Similarly, Your- 
don’s observation has not been fully trans¬ 
lated into practice. The software methods 
that are employed widely today were de¬ 
veloped before interactive end user appli¬ 
cations became important. They do not 
provide for an early and continual focus on 
users — quite the contrary. Traditional 
structured analysis relegates the task of 
establishing a “man-machine interface” to 
one subphase of system development. 6 
Jackson System Development “excludes 
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the whole area of human engineering in 
such matters as dialog design.... It excludes 
procedures for system acceptance, instal¬ 
lation, and cutover.” 7 Because such meth¬ 
ods do not specify user involvement in 
design, project plans do not anticipate it, 
and development organizations are not 
structured to facilitate it. In fact, organiza¬ 
tional structures and processes often work 
against user participation. 

Many development projects do not in¬ 
clude direct user involvement. Such projects 
indirectly acquire knowledge about system 
users, finding ways to bridge the gap be¬ 
tween developers and users. These indirect 
methods sometimes work, but they may 
not meet the rising expectations of computer 
buyers and users. 

Terminology. The authors above em¬ 
ploy the term “user” when referring to the 
people directly engaged with the system, 
sometimes called “end users.” I follow 
their lead in equating “user” with “end 
user.” Terms such as “customer” and 
“buyer” refer to other people involved in 
system acquisition and use. Similarly, 
“developers” refers to active members of a 
development project, a relatively narrow 
definition that excludes those in manage¬ 
ment and support roles, whose contributions 
are described separately. Of course, de¬ 
velopers are also users of the tools and the 
development system. 

The term “functionality” describes the 
high-level system or application functions 
or operations that relate to the work the 
software supports, while “interface” or “user 
interface” describes the lower level opera¬ 
tions and features that define the way users 


interact with the system. From the users’ 
perspective, the functionality and the in¬ 
terface are intertwined aspects of usability 
and utility, but in a given project, the terms 
can be defined at different times by differ¬ 
ent people. 

Identifying developers 
and users 

Figure 1 presents three paradigms for 
software project development based on 
when users and developers are identified. 
The left edge of each horizontal bar repre¬ 
sents the point when many of the project’s 
developers or eventual users are known. Of 
course, not every project matches one of 
these time courses precisely. Also, it can 
be difficult to pin down events to one 
moment in time. 

This framework best applies to projects 
that begin with a decision to build, modify, 
or replace a system or application and in¬ 
clude a planned completion or delivery 
date. The three development paradigms 
describe a large set of projects that have 
significantly influenced interactive systems 
development. 

In contract development or software ac¬ 
quisition, the user organization is known 
from the outset, but the development orga¬ 
nization is identified after a contract is 
awarded. The clearest cases involve com¬ 
petitive bidding; for example, a govern¬ 
ment agency prepares a design specifica¬ 
tion for a new computer system and awards 
the contract to the developer with the most 
responsive bid. Actual practice can involve 
ambiguity or complications. The user or¬ 


ganization may have some idea of who will 
get the contract; the user population may 
change before the system is completed, 
perhaps due to system personnel require¬ 
ments; and contracts may be awarded in 
stages. But the essence of contract devel¬ 
opment is that the users are identified be¬ 
fore the developers. 

In product development, also called 
commercial off-the-shelf or shrink-wrap 
software development, the developers are 
known from the outset, but the users often 
remain unknown until the product is mar¬ 
keted. Of course, all product development 
begins with some idea of the intended 
customers, whether existing or new. But 
uncertainty about the eventual user popu¬ 
lation is an important facet of product de¬ 
velopment, as the unexpected fates of many 
products, positive as well as negative, re¬ 
mind us. The IBM PC and the Apple 
Macintosh are successful systems whose 
markets were not initially foreseen, whereas 
the designers of countless failed products 
anticipated user populations that did not 
materialize. 

Finally, in in-house development, also 
called internal or information systems devel¬ 
opment, both the users and the developers are 
known at the project outset. (For example, a 
bank’s computer services division develops 
a system for the bank’s platform managers.) 
The user population may evolve or be too 
large or too dispersed to deal with individu¬ 
ally, but the degree of initial identification is 
very high. This also occurs in custom de¬ 
velopment, where a specific external devel¬ 
oper is engaged from the start to produce a 
system for a specific customer. 

Projects may not be pure expressions of 
one paradigm. When a contract is negotiat¬ 
ed without bidding, the developer has greater 
early involvement and encounters fewer 
restrictions on user access, a situation that 
lies somewhere between competitively bid 
contract development and in-house/custom 
development. Another paradigm merge 
occurs when a development company ac¬ 
quires a contract for a single system with 
the idea of subsequently developing it into 
a product. Similarly, an in-house project 
acquires some characteristics of product 
development when the organization features 
a large, diverse, and geographically dis¬ 
persed user population (for example, when 
a bank’s data processing department de¬ 
velops a system for branches that vary in 
size and operation). 

It is not surprising that conditions for 
user participation vary across these devel¬ 
opment contexts. The timing gap between 
user and developer involvement in a prod- 
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Figure 1. Project time lines with points of user and developer identification. 
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uct or competitively bid contract develop¬ 
ment project is an obstacle to collabora¬ 
tion. Many aspects of development practice 
have evolved to “communicate across time” 
— to bridge the gaps shown in Figure 1 — 
as well as to bridge the physical distances 
that often separate developers and users. 
These “bridges” or mediators include con¬ 
sultants, independent or third-party software 
developers and vendors, domain experts 
hired by development companies, internal 
market research or development groups, 
users and standards organizations, and 
flexible or multistage contracts. 

Such mediation works better in some 
cases than in others. Keep in mind the 
chorus of recommendations that interac¬ 
tive systems developers establish and 
maintain continual contact with users, and 
the widening gulf between development 
and user environments. Intuition has become 
a less reliable guide to development, and 
theeffectiveness of replacing it with indirect 
contact between developers and users must 
be continually reexamined. 

Three development 
contexts 

Each of the paradigms or contexts in 
Figure 1 has contributed to contemporary 
practices of developing interactive sys¬ 
tems while maintaining its own history, 
literature, and even language. Contract 
development has been central to the evo¬ 
lution of software project management 
methods; product development has focused 
attention on computer interfaces to indi¬ 
vidual users; and in-house development 
has explored social and organizational as¬ 
pects of system use. Many people work 
exclusively in one paradigm or another. 
Understanding the different perspectives 
can eliminate some of the resulting con¬ 
fusion and allow us to evaluate approaches 
that are based on unfamiliar research and 
development experiences. 

Contract development and a focus on 
software methods. From the beginning of 
commercial computer development, gov¬ 
ernment contracts have been a powerful 
force in the industry. The United States 
government has been and remains the larg¬ 
est computer user. 8 Government-initiated 
large-scale projects focused attention on 
software development methods. 

Major contributions to the stage model 
of systems development were first described 
at a 1956 Office of Naval Research Sym¬ 
posium and a 1966 Air Force Exhibit. 4 The 
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waterfall model of the software life cycle 
became the basis for most government 
software-acquisition standards. This mod¬ 
el describes an unvarying sequence of phases 
in which feasibility is established, require¬ 
ments are specified, and preliminary and 
detailed designs are drawn up prior to 
coding. Then, these phases are followed by 
testing, integration, implementation (or 
installation), operation, and maintenance. 
This provides minimal opportunity for 
prototype testing and iterative design, which 
form the basis of ongoing user involve- 

The waterfall model restricts prototyp¬ 
ing to “build-it-twice” development and 
restricts further iteration to feedback from 
adjacent phases. These limitations were 
recognized early by some software devel¬ 
opment managers and have been a source 
of criticism that has gathered force with the 
spread of interactive systems. But, the 
waterfall model is a natural fit to compet¬ 
itive contract development, where the user 
organization determines feasibility, pre¬ 
pares a requirements specification, and then 
issues one or more contracts for design, 
development, administration, and mainte- 

The waterfall model and its refinements 
were suited in other ways to the large, often 
government-contracted systems that dom¬ 
inated early systems development. The 
heavy emphasis on early design is more 
successful for relatively predictable, non¬ 
interactive systems, which have less un¬ 
certainty about requirements than systems 
that support substantial user interaction. In 
addition, the documentation and the dis¬ 
tinct phases facilitate creation of an audit 
trail. 

Strongly promoted by IBM, the water¬ 
fall model became the foundation for many 
structures and procedures found in most 
systems development. However, for to¬ 
day’s interactive systems developer, the 
reliance on specifications documents im¬ 
poses a “wall” between users and develop¬ 


ers. This wall may not be impenetrable, but 
it clearly impedes user-based iterative de¬ 
sign. The other development contexts are 
slowly freeing themselves from the prob¬ 
lematic organizational structures and de¬ 
velopment practices that originated in 
contract development. 

Product development and a focus on 
the user interface. As hardware costs fell 
and the market for computer systems 
broadened during the 1960s and 1970s, 
off-the-shelf product development grew in 
importance, especially in the United States. 
The discretionary nature of product ac¬ 
quisition means that systems must appeal 
to people, rather than meet written re¬ 
quirements specifications. However, 
product developers are buffered from end 
users by two intermediaries: the market 
and the customer. 

With a large number of possible users, a 
product can do very well if only a fraction 
of the market finds it acceptable. In addi¬ 
tion, especially in less mature markets, the 
product generally has to appeal to the 
customer — the person who makes the 
purchasing decision, often a manager or 
information systems specialist — not the 
end user. These customers share with the 
product development company the job of 
assuring system acceptance. The customer 
can hire systems administrators, provide 
training, establish internal development 
groups to tailor the product, supplement 
the product with third-party software, or 
even mandate use. Thus, just as the speci¬ 
fication requirement in contract develop¬ 
ment is a wall between developers and 
users, the market and the customer in product 
development represent a thick hedge. In¬ 
formation about users’ needs gets through, 
but it takes time and is muffled. Individual 
voices are not heard. 

The delay in responding to users’ needs 
allowed product development companies 
to focus on functionality, even if they met 
the usability needs of only a fraction of the 
potential users. Product development or¬ 
ganizations could postpone attending to 
the human-computer dialogue while slow¬ 
ly finding indirect methods (consultants, 
market research, user groups, shows, trade 
press, etc.) to learn about major user needs. 
Now, as usability expectations increase in 
more mature software markets, product 
development companies are entering the 
phase in which users’ needs replace soft¬ 
ware constraints as the dominant influence 
on development. We will see that the in¬ 
direct, mediating organizational structures 
and processes that product developers 
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formed to bridge the gap to users often 
inhibit direct user-developer contact. 

Muffling individual users’ voices meant 
that in the 1980s, as computer use spread 
and usability became an issue, product 
developers focused on the generic aspects 
of the human-computer dialogue that are 
shared by almost all users. Motor control, 
perception, and lower cognitive processes 
— the “look and feel” of software — were 
explored by researchers and developers in 
the field of human-computer interaction. 
Since the hardware, the software environ¬ 
ment, and product functionality are typi¬ 
cally specified before a product develop¬ 
ment team is formed, only these aspects of 
the user interface design remain to be de¬ 
fined. 

A community focused on interface is¬ 
sues coalesced in 1983 with the formation 
of the ACM Special Interest Group on 
Computer and Human Interaction (SIG- 
CHI). Industry representation at the annual 
CHI conferences and in the related jour¬ 
nals (such as Human-Computer Interac¬ 
tion, established in 1985) has come pre¬ 
dominantly from product development 
companies. 

Developers could safely ignore social or 
organizational concerns when the spread 
of multitasking systems and personal com¬ 
puting made single-user systems and ap¬ 
plications very profitable. The design and 
use of word-processor or spreadsheet pro¬ 
grams, for example, are relatively inde¬ 
pendent of the social context in which they 
are used. The profits enabled American 
product development companies to form 
research groups, recruit heavily from lead¬ 
ing universities, and influence the direc¬ 
tion of academic research. 

This field, human-computer interaction, 
has had less involvement from those work¬ 
ing in contract development, where usabil¬ 
ity is taking even longer to come into focus. 
In-house development also remains rela¬ 
tively uninvolved, due in large part to dif¬ 
fering interests: Internal development must 
focus on the individual and group differ¬ 
ences and social dynamics that product 
developers can ignore; these are central to 
the acceptance of a specific in-house or 
custom-built system. In addition, the nar¬ 
row “user interface” focus is less useful to 
in-house developers, who are more likely 
to consider functionality and its interface 
together. 

In-house and custom development and 
a focus on user participation. In-house or 
internal development, in which the devel¬ 
opers and users work under the same cor- 
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porate roof, was the original development 
context. The early developers were also 
the users of their own systems. In the Unit¬ 
ed States today, the other contexts have 
achieved greater visibility through their 
concentration of resources and association 
with the major computer manufacturers. 
But in-house development is a major gen¬ 
erator of software (and in much of Europe, 
it is the most visible). This paradigm affords 
an obvious potential advantage to user 
participation in design: The developers and 
the eventual users are known when the 
project is initiated. 

Potential obstacles to success do exist. 
Projects for multiuser systems are more 
challenging than single-user applications. 
Also, along with any benefits received by 
adopting the specifications-based water¬ 
fall model, internal developers created the 
documentation “wall” between themselves 
and users. This wall has less purpose in this 
environment, and it comes down immedi¬ 
ately when the system is completed. 

Many system design challenges for end 
users were first experienced in in-house 
development, where success required that 
a predefined set of users accept the system. 
Successful contract development requires 
conformance to a written specification; 
successful product development does not 
depend on appealing to a specific individ¬ 
ual or group. But an internal development 
project must be accepted by a set group of 
users. 

By the late 1970s or early 1980s, user 
needs replaced software constraints as the 
dominant concern within internal systems 
development. 8 It is not surprising that this 
occurred as soon as interactive systems 
began replacing batch processing. (A sim¬ 
ilar transition is under way, a decade later, 
in product development. Its arrival has 


been delayed by the market and the cus¬ 
tomer, which stand between off-the-shelf 
product developers and their users.) De¬ 
sign approaches based on active user in¬ 
volvement gathered strength, notably in 
British and Scandinavian projects. Many 
were collaborations between researcher- 
developers and specific user organizations; 
they shared the in-house development 
characteristic of identifying developers and 
prospective users at the outset. 

Cultural and political factors, including 
a strong trade union movement, are often 
credited for the Scandinavian interest in 
collaborative design. While these factors 
surely contribute, the dominance of the in- 
house and custom development paradigm 
in these countries presented precisely the 
right motivation and conditions for such 
experiments. Unlike the situation in the 
United States, research and development 
resources were not absorbed by large com¬ 
petitively bid government contracts or by 
product development, contexts in which 
user needs have been slower to come into 
focus and in which conditions for engaging 
users in development are less favorable. 

Today, usability is becoming more im¬ 
portant to product and contract develop¬ 
ment organizations. These organizations 
are still to some extent buffered from the 
end users by the size of the product market 
and by the reliance on contract documents. 
However, resistance to unfriendly systems 
is growing. There is growing competitive 
pressure for usability in the marketplace, 
particularly in mature application domains, 
and greater focus on the human-computer 
dialogue in contracts. The success of the 
Macintosh in the mid-to-late 1980s was a 
turning point — a good interface drove 
hardware and software sales. 

Product and contract developers who 
foresaw the importance of usability en¬ 
countered obstacles to involving users. Few 
successful cases of user participation in 
development have been reported. For this 
reason, some researchers and developers 
are turning to Europeans who have a track 
record in such collaborations. For exam¬ 
ple, at the 1988 ACM-sponsored Confer¬ 
ence on Computer Supported Cooperative 
Work held in Portland, Oregon, six of the 
30 presentations were based on the Scandi¬ 
navian approach. (Recent books and arti¬ 
cles on this approach are listed in “Further 
reading.”) Thus, just as contract and prod¬ 
uct development have influenced interac¬ 
tive systems development, work originat¬ 
ing in in-house development contributes 
techniques and approaches. 

Product and contract developers can gain 
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insight from the European approaches, but 
must bear in mind that in-house develop¬ 
ment is a different context. Today, product 
development projects in particular have 
acquired the same motivation to involve 
users that in-house development projects 
had 10 years ago. However, they experi¬ 
ence different conditions within which to 
engage users. Roadblocks to a strong focus 
on users include the timing of involvement 
shown in Figure 1, as well as the organiza¬ 
tional structures and processes that were 
established before the importance of the 
interaction dialogue. Adapting to the new 
situation may ultimately require substan¬ 
tial organizational change. We can guide 
that change, and work effectively in the 
meantime, by identifying each paradigm’s 
unique advantages and disadvantages for 
realizing successful user participation in 
design and by understanding the alterna¬ 
tives to direct user involvement and their 
limitations. 

Factors influencing 
interactive systems 
development 

Before exploring the opportunities and 
obstacles that each paradigm offers, let’s 
consider several constraints on develop¬ 
ment projects that influence the conditions 
for user contact. One constraint, the time 
for involving development partners, was 
used to identify the three development par¬ 
adigms : a single user organization for which 
there are many potential developers (con¬ 
tract development), a single development 
group with many potential users (product 
development), and a single development 
group with a single user organization (in- 
house development). Other factors include 
the size, charter, and structure of the devel¬ 
opment organization; the nature of the user 
population; the degree of design uncertain¬ 
ty; the presence or absence of other part¬ 
ners or contributors to the project; the na¬ 
ture of the commitments and agreements 
among the parties involved; societal con¬ 
ditions that the partners may be unable to 
control; and changes encountered over the 
life of the project. 

The size of the development company 
or organization. This article generally 
focuses on projects in large organizations. 
A start-up or a small product development 
company may have fewer resources, less 
division of labor, fewer installed customer 
base concerns, and may succeed with far 
fewer sales than a larger company. These 
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factors permit greater flexibility, more lat¬ 
itude for (inexpensive) innovation, and, 
particularly significant for user involve¬ 
ment, the possibility of focusing on a few 
potential customers (perhaps even finding 
a customer willing to cosponsor develop¬ 
ment). In these ways, a small product de¬ 
velopment company takes on some 
characteristics of in-house or custom de¬ 
velopment. 

At the other end of the size continuum, 
very large companies also present mixed 
appearances. A large telecommunications 
company, for example, blends substantial 
internal development with opportunities 
for product development provided by its 
large, identifiable market. Similarly, in a 
highly divisionalized company, one divi¬ 
sion may “sell” its product to another or 
even bid for an internal contract to deliver 
a system. 

The charter of the company or organi¬ 
zation. Organizational charters vary, and a 
company may work in more than one par¬ 
adigm. For example, large product-devel¬ 
opment companies pursue government 
contracts for systems that can be built on or 
around their products. A separate Federal 
Systems Division may manage these 
projects, but influences often cross divi¬ 
sional boundaries. Paradigms alsoblur when 
a product development company that con¬ 
siders entry into a new market experiments 
by custom building a system for one cus¬ 
tomer to obtain domain expertise. The 
Scandinavian UTOPIA project (an acro¬ 
nym in the Scandinavian languages for 
“training, technology, and products from 
the quality of work perspective”) did the 
reverse experiment: Methods from the in¬ 
house/custom development paradigm were 
adapted to a product development effort. 9 


An organizational charter shifts gradually 
when a company develops a system under 
contract to one user organization, then de¬ 
cides to market it more broadly. Finally, 
several influential Scandinavian projects 
have involved development teams drawn 
from university research laboratories, small 
groups with a mixed agenda of research 
and development interests. 

Organizational structures and proce¬ 
dures. Companies that do similar work do 
not necessarily divide responsibilities and 
meet obligations in the same way. While 
certain job descriptions and work proce¬ 
dures are widespread in the industry, com¬ 
panies of similar size and charter organize, 
distribute authority, and approach system 
development differently. Marketing divi- 
sons drive some companies, while engi¬ 
neering drives others. Some are hierarchi¬ 
cal bureaucracies, others are strongly 
divisionalized into semiautonomous sub¬ 
units, and some have experimented with 
almost ad hoc approaches. An in-house 
project in a large, divisionalized company 
may be managed through a contract com¬ 
peted for by internal development groups. 
Even where high-level approaches to orga¬ 
nizational structure and process are simi¬ 
lar, small variations in structure and pro¬ 
cess can greatly affect individual 
development projects. Within a single 
company, such variation results from in¬ 
ternal reorganizations. 

The nature of the system user popula¬ 
tion. The generic term “user” masks a 
tremendous diversity of computer users 
and contexts of use. This diversity will 
continue to increase — even if progress in 
hardware development stopped today, cur¬ 
rent technology would take decades to re¬ 
alize its potential. The number and hetero¬ 
geneity of users is often a particular concern 
to in-house development. More generally, 
some users are captive audiences, who use 
systems acquired for them by others, while 
others are discretionary users. At the ex¬ 
treme end of discretionary use, those who 
pay for their own systems become involved 
through their personal economic stake. An 
Apple developer told me, “We don’t have 
to ask our users for advice; they volunteer 
it.” 

The physical separation of developers 
from some or all users is often critical, as 
are barriers of class, culture, or language. 
The sensitivity of the users’ work is anoth¬ 
er factor: A group designing a system for 
the CIA may have to accept a limit to their 
ability to “know the users.” 
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The degree of design novelty or uncer¬ 
tainty. The uncertainty that arises in de¬ 
signing for a new market or in utilizing a 
new medium not only affects the motiva¬ 
tion for working with users but also affects 
the conditions for doing so. Experienced 
users are more easily found in a mature 
application area, and mediators — con¬ 
sultants, trade publications, empirical re¬ 
search — are more reliable sources of in¬ 
formation about users or technical 
alternatives. 

Mediators: additional partners in the 
development project. Although I have 
primarily considered users and develop¬ 
ers, projects generally involve other par¬ 
ties. These parties include other groups 
within the development and user organi¬ 
zations, as well as external consultants, 
subcontractors, value-added resellers, in¬ 
dependent software vendors, third-party 
developers, product user organizations, 
trade unions, and standards organizations. 
Inanimate mediators include published 
guidelines, trade publications, and trade 
shows. 

The roles of such mediators are some¬ 
times central, sometimes incidental; they 
include informing developers of users’ 
needs and informing users of technological 
opportunities. A critical uncertainty in in¬ 
teractive systems development is the ade¬ 
quacy of these channels for indirect collab¬ 
oration in development. 

Commitments and agreements among 
the groups involved. Commitments vary 
in formality and scope, ranging from infor¬ 
mal understandings between individuals 
within one organization to binding con¬ 
tracts among companies. They also vary in 
content, focus, and flexibility. The content 
can be restricted to technical aspects of the 
system or can include such commitments 
to the users as organizational impact state¬ 
ments, installation, or training. Similarly, 
an agreement can be restricted to the sys¬ 
tem to be developed or can specify aspects 
of the development process, including 
techniques to facilitate user involvement, 
such as prototyping or scheduled reviews. 
Contracts vary in flexibility — even a for¬ 
mal contract might include a level-of- 
effort provision or specify times at which 
its terms can be reconsidered, permitting 
design changes based on user involve- 


Societal conditions and change over 
time. Projects encounter dynamic influ¬ 
ences that the development partners cannot 


directly control. 10 These influences include 
aspects of the labor market, economic 
considerations of supply and competition, 
available technology, formal standards, and 
legal restrictions on technology use or 
safeguard requirements. Finally, the factors 
described in this section are subject to 
change within the life of a project; it is a 
rare project that enjoys static conditions 
from start to finish. 

Focusing on users: 
Opportunities, 
obstacles, and 
mediators 

Each project has particular advantages 
and disadvantages for involving users and 
specific strategies to cope with the gaps 
between developers and prospective users. 
These are explored here at the more gen¬ 
eral level of the three development para¬ 
digms. 

Contract development. User involve¬ 
ment faces the most formidable obstacles 
in this context, especially with fixed-cost 
competitively bid contracts. 

Opportunities. Starting with a well- 
defined user population is an advantage in 
obtaining user involvement. Of course, the 
users themselves do not write the specifica¬ 
tions, but the opportunity exists to enlist 
their cooperation. (However, when specifi¬ 
cations address only system function, such 
user involvement stops short of contribut¬ 
ing to the user interface.) Also, contract 
development projects are often relatively 
large and slow moving (in contrast with an 
application upgrade, for example), which 
could provide substantial resources and time 
for iterative development with user in¬ 
volvement. High-level management is 
committed to the success of the project, 
which is an important factor in system ac¬ 
ceptance. Finally, within constraints de¬ 
scribed below, the user organization has the 
power of authoring the contract and thus 
can obtain greater user involvement either 
directly or indirectly (that is, contract pro¬ 
visions may require prototyping or periodic 
review; interface features, usability targets, 
training requirements, or an organizational 
impact statement may be specified). 

Obstacles. Consider a composite case 
described by Gundry": The user organiza¬ 
tion, a large government agency, prepares 
a requirements specification. This is fol¬ 


lowed by a request for proposals (RFP) to 
develop the system design. A contract is 
awarded. This work results in a design 
specification that is the basis for an RFP 
for system development, which leads to the 
development contract award. 

In the initial requirements specification 
executed within the large bureaucracy, user 
involvement is not assured. If a task anal¬ 
ysis is done at all, it may rely on a few 
interviews of users or supervisors. Although 
interaction can occur before the RFP is 
issued, communication between designers 
in the bidding organizations and anyone in 
the user organization is then sharply cur¬ 
tailed and monitored to prevent a bidder 
from acquiring an unfair advantage. 

When the contract for design is award¬ 
ed, the designers work to the specification; 
by avoiding contact with the user organiza¬ 
tion, they avoid influencing the subsequent 
bidding on the more lucrative development 
contract. Since the follow-on development 
contract can be awarded to another compa¬ 
ny, the designers do not necessarily know 
who the developers will be. And, when the 
same company does obtain both the design 
and development contracts, as often hap¬ 
pens, the development team is usually dis¬ 
tinct from the design team, which has moved 
on to other design proposals. In addition, 
companies minimize risk by preparing joint 
bids, which spreads development across 
two or more organizations. 

Contact with users continues to be con¬ 
trolled during development. This is for 
security or geographic separation reasons 
or to avoid influencing later bidding (on 
system administration, for example, or on 
system maintenance, which is often the 
most lucrative contract of all). 

The designers and developers have an¬ 
other reason to avoid contact with users. 
Contract compliance is based on conform¬ 
ance to the written specifications. Any de¬ 
viation from the specification is to be 
avoided: Programmers have been known 
to code nonfunctioning procedures de¬ 
scribed in miswritten specifications to avoid 
jeopardizing compliance. The development 
organization might prefer to commit to a 
relatively comprehensible and static docu¬ 
ment rather than try to satisfy unpredictable 
users. Usability requirements in contracts 
for interactive systems can be as vague as 
“the system shall present information suc¬ 
cinctly” or “the system shall be easy to 
operate efficiently.” 11 

Some contracts require that prototypes 
be demonstrated to users yet preclude or 
discourage changes based on feedback from 
the demonstrations. This only serves to 
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alert users to the inadequacies of the sys¬ 
tem they will receive. When changes are 
possible, the developers may not learn much 
beyond “the system is unusable.” 

Mediators. Figure 2 shows several groups 
that serve as intermediaries, educating sys¬ 
tem users about contract developers and 
vice versa. Within a user organization, sys¬ 
tem analysts or engineers specify require¬ 
ments, and contract specialists or monitors 
handle negotiations. Similar professionals 
in the development organizations write 
proposals and negotiate contracts, with 
developers not assigned to a project until 
contract award. 

External consultants help the user orga¬ 
nization by playing a surrogate developer 
role during requirements definition, pro¬ 
viding the contracting organization with 
insight into feasible technologies. Although 
consultants are more likely to deal with 
managers or specialists, they may actively 
participate with users. Contractors work¬ 
ing on one phase of the project are in a 
sense consulting on subsequent phases; for 
example, those who write the design spec¬ 
ification provide guidance to the as-yet- 
unidentified developers. Similarly, devel¬ 
opers who are barred from direct access to 
real users employ consultants familiar with 
the target environment to serve as surro¬ 
gate users or hire domain experts away 
from a large customer to help staff the 
project. 

User organizations address eventual 
shortcomings in the system through modi¬ 
fications by in-house or third-party devel¬ 


opers. More broadly, contractors commu¬ 
nicate their needs by working collectively 
with vendors to develop formal standards, 
adherence to which may be mandated in 
subsequent contracts. (A large enough cus¬ 
tomer organization, such as the United 
States Department of Defense, can by itself 
promote standards development and com¬ 
pliance.) Gundry 11 proposes that the con¬ 
tracting organization supplement the re¬ 
quirements specification with a “concepts 
of use” document: an extended description 
of the users, their work practices, and their 
working organization. That this static view 
of the users’ environment is perceived by 
Gundry as a major step forward is a dra¬ 
matic statement of how little contact be¬ 
tween developers and users currently exists. 

Government contracts impose further 
challenges to developing more usable sys¬ 
tems. Cost-plus contracts reduce the in¬ 
centive to reuse successful components; in 
fact, using a similar interface can suggest 
that the government is being charged twice 
for the same work. In addition, contractors 
who are also engaged in product develop¬ 
ment may be reluctant to place their best 
work in the public domain by including it 
in a government-owned system. 

On the positive side, concurrent engi¬ 
neering and computer-aided acquisition and 
logistic support are new approaches that 
reduce development time by using central¬ 
ized databases and multidisciplinary teams 
to reduce the emphasis on phased develop¬ 
ment. While designed for other purposes, 
the increased communication and coordi¬ 
nation could promote continuous customer 


and user participation. Also, as noted above, 
the contract itself may be used to open up 
communication. Contractors may be re¬ 
quired to describe planned human factors 
activities. Where legal barriers do not in¬ 
tervene, user involvement can be speci¬ 
fied. Even a formal contract may address 
the uncertainties of dialogue design by 
providing points for renegotiation of con¬ 
tract terms based on prototype testing. 10 
Experiments have been tried with design- 
to-cost contracts, reward-for-effort con¬ 
tracts, and “buy-downs” or “fly-offs”: 
multistage contracts with a “competitive 
conceptual development phase” in which 
several developers build and test proto¬ 
types before the final development con¬ 
tract competition. 

Product development. This context 
provides a strong incentive to increase us¬ 
ability, but user involvement is a challenge 
when the potential users are numerous yet 
faceless. 

Opportunities. Because development 
costs are amortized over many sales, prod¬ 
uct development organizations typically 
have considerable resources and many po¬ 
tential users that could be drawn upon to 
improve usability. Competition in the mar¬ 
ketplace provides a motive for doing so — 
the attention given to “look and feel” re¬ 
flects the growing awareness of the impor¬ 
tance of usability. Product development 
companies are major employers of human 
factors engineers, technical writers, and 
other user interface specialists. Continual 
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product upgrades or new releases free some 
developers from “single-cycle” develop¬ 
ment. They evaluate existing practice and 
feed it into the next version’s design, and 
they may save good ideas that arrive too 
late for one project for use on another one. 
Finally, while these companies can suc¬ 
cumb to inertia or conservative forces, they 
were founded on change and at some level 
recognize that survival requires openness 
to new ideas and approaches. 

Obstacles. First, the development team 
members must commit to involving users. 
Developers who are isolated in large engi¬ 
neering laboratories may not empathize or 
sympathize with users who are inexperi¬ 
enced, nontechnical, or have different val¬ 
ues and work styles. Even identifying the 
development team is difficult: Functional¬ 
ity is defined by management or marketing 
before the project team is formed, project 
membership changes over time, and the 
developers of different user interface com¬ 
ponents — such as software dialogue, doc¬ 
umentation, and training — often commu¬ 
nicate very little. In many companies, 
placing all aspects of a product’s usability 
under the same management would con¬ 
flict with deeply rooted aspects of organi¬ 
zational structure and process. 

Also, the difficulty of identifying future 
users is a major obstacle to involving them. 
Strategic marketing decisions are careful¬ 
ly guarded by upper management to prevent 
the competition from using the information. 
Development teams often do not know 
which applications will be marketed as 


packages. In addition, before reaching an 
end user, many products are extensively 
modified or tailored by third-party devel¬ 
opers or by the customer’s in-house devel¬ 
opers. These developers are users of the 
product, too. 

Another obstacle is accessing potential 
users once they are identified. They work 
in different organizations, perhaps even 
different countries. Also, product devel¬ 
opment companies tend to shield developers 
from the time-consuming task of responding 
to individual user requests. 

Figure 3 identifies several groups charged 
with knowing the needs of users: product 
management, marketing, and customer 
support in the development organization, 
and information systems specialists in the 
user organization. These go-betweens or 
mediators often discourage direct devel¬ 
oper-user contact, either overtly or by partly 
alleviating the need for it. 

These mediators are often ineffective 
conduits for usability information because 
the task is difficult and the usability con¬ 
cerns are new. It is particularly difficult in 
this context to obtain adequate time from 
potential users, who have little at stake. 
When contact does occur, product devel¬ 
opers risk overgeneralizing from a few 
contacts, and they must contend with 
conflicting views of different users. (Care¬ 
ful selection of test sites happens primarily 
for major products and relatively late in 
development.) Finally, information that is 
obtained must be worked into the develop¬ 
ment process, which is fraught with com¬ 
peting interests and trade-offs. The pro¬ 


cess was designed to maximize the predict¬ 
ability and reliability of developing nonin¬ 
teractive systems; it does not work as well 
for developing the less predictable inter¬ 
active systems. 

Another obstacle is the pressure to pro¬ 
duce new releases of existing products — 
the relatively short development cycle fa¬ 
vors small enhancements over substantial 
innovation and does not provide enough 
time for users and developers to educate 
one another. Caution is also encouraged by 
the new fear of incurring an interface 
copyright infringement suit. Emphasis on 
rapid development engenders attempts to 
routinize the process through the early ap¬ 
proval of specifications and schedules, 
which limits flexibility. 

One approach that product developers 
pioneered to overcome their separation from 
users is providing customized or tailored 
systems, which is a useful step but not a 
panacea. Another approach has been to 
rely on mediators. 

Mediators. As shown in Figure 3 and 
described above, sales and marketing de¬ 
partments, management, customer support, 
and other groups within large product- 
development companies mediate between 
users and developers. Other developers 
form part of a corporate memory that for 
usability issues can operate more effec¬ 
tively than formal records. External con¬ 
sultants serve as surrogate users, providing 
developers with detailed product critiques 
and information on market direction. Con¬ 
sulting, market research, and competitive 
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analysis, although undertaken to support 
the marketing of existing products, can 
also guide developers. Value-added resell¬ 
ers, third-party developers and indepen¬ 
dent software vendors, who adapt or match 
products to specific markets, stand between 
development and user organizations. Cus¬ 
tomer organizations engage consultants as 
surrogate developers to advise them about 
purchasing or installation. Buyers also rely 
on in-house developers to supplement or 
tailor products. 

Most customers exert little direct influ¬ 
ence on product development companies 
individually, but user groups representing 
many customers have more influence. 
However, this communication channel is 
less effective when meetings are attended 
by customers or buyers rather than users 
and by marketers rather than developers. 


In-house development. This develop¬ 
ment context appears to offer good pros¬ 
pects for collaboration among users and 
developers, but the challenges are substan¬ 
tial. One challenge is that internal develop¬ 
ment is often modeled on contract devel¬ 
opment, adopting methods that work against 
user involvement. 

Opportunities. Collaboration is logical¬ 
ly easier when users and developers are 
known from the beginning (see Figure 4). 
An early relationship can lead to parallel 
work on the functionality and the interface 
and is needed for prototyping and iterative 
design. User involvement can also help 
with system acceptance because partici¬ 
pating users acquire an interest in the out¬ 
come; they may accept system features 
that they otherwise would have resisted. 8 
In in-house development, communication 
between developers and users can be en¬ 
hanced by the shared corporate culture (but 
see below). Also, the transitions across 
development phases are smoother; in par¬ 
ticular, the developers are accessible dur¬ 
ing product introduction and use. A further 
advantage is that these projects have strong 
management support, an important element 
in obtaining system acceptance. Finally, 
they often enjoy a less pressured, more 
flexible development schedule — shifting 
focus from the product to the development 
process occurs most naturally in this envi¬ 
ronment. 

Obstacles. In-house projects are gener¬ 
ally systems or major applications designed 
to support organizations, which are more 
difficult than the single-user applications 



that dominate software product develop¬ 
ment. In addition, identifying future users 
is easier than ensuring collaboration. Large 
companies may impose geographic as well 
as organizational separations. Conflicts of 
interest exist within organizations: Man¬ 
agement or information systems staff 
themselves may be the principal beneficia¬ 
ry of a project; if their interests conflict 
with the end users’, user alienation is more 
likely than cooperation. Conflicts also oc¬ 
cur among different worker groups—Ehn 9 
describes jurisdictional disputes among 
typesetters, journalists, and administrative 
workers in one project. Friction between 
developers and users can result from dif¬ 
fering codes of values, conduct, and dress, 
as well as disparities in age and salary. 8 

Selecting representative users is a chal¬ 
lenge. Not all potential users have the time 
or inclination to participate fully, manage¬ 
ment may wish to participate or to control 
participant selection, and workers with 
greater knowledge of technology may be 
more interested but less representative. 
Potential participants’ political roles in the 
organization must be balanced against their 
roles as system users. In addition, some 
techniques must be used very carefully in 
internal development — rapid prototyping 
can unduly raise users’ expectations of the 
system’s capabilities or state of comple¬ 
tion. (This problem also appears as the 
rapid-prototyping technique is introduced 
in contract development; in product devel¬ 
opment, where disappointing one potential 
user is not as serious, the risk is that devel¬ 
opment management will be misled.) 

Fewer resources may be available to in¬ 


house development projects than to con¬ 
tract or product-development projects. 
Building a single system to be used for 
many years provides less opportunity for 
evaluation, feedback, and catching missed 
opportunities the next time around than is 
found in product development. Prototyp¬ 
ing and iterative design are not infinitely 
flexible, so the in-house development team 
must plan very carefully, considering, for 
example, the likely organizational impact. 
Such planning is beneficial, but given the 
inherent uncertainty of interactive systems 
development, the need to anticipate cor¬ 
rectly is not an advantage. 

Mediators. The spread of interactive 
systems in the early 1980s immediately 
confronted in-house developers with the 
needs of end users. The mediators who 
enabled the other developers to adjust slowly 
while delaying their entry into this phase 
are less available to in-house developers. 
Only upper management or human resources 
departments typically intervene between 
internal developers and users. 

Friedman 8 explores five possible ap¬ 
proaches to bridging the gap between users 
and developers in internal development: 
direct user participation in development 
based on traditional methods, end user 
computing (effectively, trying to eliminate 
developers by providing systems that can 
be tailored or customized by users), de¬ 
centralizing the information center (to bring 
developers into closer contact with users), 
changing the systems development ap¬ 
proach (through a process focus, notably 
an emphasis on prototyping and iterative 
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design), and relying more heavily on infor¬ 
mation systems specialists with both do¬ 
main expertise and development skills. 
These are not mutually exclusive: The 
Scandinavian experiments have simulta¬ 
neously employed direct user involvement, 
prototyping, and the education of developers 
about the domain area. In fact, these ap¬ 
proaches are all forms of user participation, 
if participation is extended to include the 
education that precedes a particular project. 


S everal convergent forces push in¬ 
teractive systems development to¬ 
ward greater concern for users’ 
needs. First, reaching untapped markets 
requires learning more about them. Com¬ 
puter versatility enhances the likelihood of 
finding a way to support a group of people 
whose concerns are properly understood. 
Second, users who can choose their tools 
will be influenced by usability in exercis¬ 
ing this discretion. The focus on “look and 
feel,” while reflecting aesthetic as well as 
utility judgments, arises from the avail¬ 
ability of functionally equivalent product 
alternatives in mature markets. Third, un¬ 
derstanding user needs is more central to 
software support of groups. 

Until recently, mainframe systems fo¬ 
cused on supporting organizations while 
most micro- and minicomputer applications 
focused on supporting individuals. Now, 
networking and multitasking systems make 
group-level support feasible. “Groupware” 
product developers face issues that were 
previously encountered mainly in in-house 
development as the focus of application 
development shifts from individual simi¬ 
larities (with the goal of appealing to a 
large group of similar people) to individual 
differences and social dynamics (to attract 
all members of groups, independent of 
background, role, or preferences). Here, 
application developers are at a disadvan¬ 
tage relative to system developers, since 
there is less corporate commitment to en¬ 
suring the acceptance of a groupware prod¬ 
uct than a large system. Finally, the cost of 
computation was a major obstacle to pro¬ 
viding more usable systems. As processing 
time, memory, and maintenance costs con¬ 
tinue to fall, more computational power is 
devoted to handling user interaction. To¬ 
day, the price to obtain a better interface is 
not much more than the cost of building or 
buying one. 

In summary, computer vendors’ inter¬ 
ests, computer users’ interests, and eco¬ 
nomic factors work in concert to encour¬ 
age the development of more usable 


software. Further progress will result from 
sharing experiences across the three devel¬ 
opment contexts. Conferences such as the 
1988 Computer Supported Cooperative 
Work Conference and the 1990 Participa¬ 
tory Design Conference in Seattle bring 
together Scandinavian and American re¬ 
searchers and developers from in-house 
and product development. 

Boehm 4 outlines recommendations for 
contract development drawn from in-house 
development experience. Techniques de¬ 
veloped in one context can be modified and 
applied in others. The process focus and 
low-cost techniques that developed natural¬ 
ly in in-house development environments 
are being applied more broadly. Prototyp¬ 
ing techniques first used in product devel¬ 
opment are being adapted to in-house 
projects. Further contact occurs as in-house 
projects come to rely more heavily on off- 
the-shelf software product components and 
as contracts specify more standard platform 
products. 

The prevalence of specific development 
contexts may shift with societal changes. 
For example, the current integration of the 
European community will promote com¬ 
petitively bid contract development to en¬ 
sure equal access to large projects. Europe¬ 
ans may profit from American experience 
and find ways to introduce approaches that 
achieve higher levels of user involvement. 

Such communication requires effort. 
Many interests are not shared; there are 
specialized terminologies, journals, trade 
publications, conferences, and shows. Even 

I word meanings vary across development 
contexts; for exampl e, “implementat i on" is 
a synonym for “development” or “coding” 
to product developers, whil e it means “in¬ 
stallatio n” or “adoption” elsewhere. “End 
user” or~ n operator”toan in-nouseaevelop- 
er is just “user” in a product environment. 

Procedures take on different appear¬ 
ances: To a contract or in-house developer, 
a “task analysis” generally addresses repet¬ 
itive activity carried out in an organization¬ 
al context by an “operator” hired to perform 
it, whereas to a product developer, a “task 
analysis” is more often a cognitive analysis 
of individual behavior in a less structured, 
discretionary use situation. 

Techniques are viewed differently: Inter¬ 
nal developers (and many in the research 
community) link software “evaluation” to 
testing that occurs late in development, when 
only minor design changes are possible; in 
contrast, product design is more likely to 
begin with the evaluation of existing prod¬ 
ucts or versions, so “evaluation” has a less 
negative ring to product developers. 


Finally, confusion may result from fail¬ 
ing to differentiate among the contexts, as 
illustrated by the debate over the routiniza- 
tion of software development. In large 
product development organizations, strong 
competition and the pressure for frequent 
releases create a strong desire to control the 
development process and to render it immune 
to the loss of any individual — conditions 
leading to “deskilling,” where individual 
developers are given less responsibility and 
become more expendable. However, a ten¬ 
dency toward deskilling is not reported in 
internal development, where competitive 
pressures are lower and developers increase 
their value to their organization by acquir¬ 
ing domain knowledge. 8 

References to “the computer industry” 
disguise the multiplicity of computer indus¬ 
tries that have evolved. They share a need to 
examine current practices and search for 
new ones to meet the challenge of developing 
usable, useful interactive software. Only by 
recognizing the range of existing conditions 
and their effects can we adapt the hard- 
earned lessons of one development context 
and apply them in others. The potential 
benefits are new techniques, processes, and 
organizational structures for development. ■ 
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Preparing for EC 1992 in the US through quality system registration 

Joseph Tiratto, ABS Quality Evaluations Inc. and Registrar Accreditation Board 


The 12 nations of the European Com¬ 
munity are planning the unification of 
Western Europe as an “internal market” 
by 1992. When their plans are fully im¬ 
plemented, the EC countries — Belgium, 
Denmark, France, Germany, Greece, Ire¬ 
land, Italy, Luxembourg, the Nether¬ 
lands, Portugal, Spain, and the United 
Kingdom — will be transformed into a 
single, integrated market of 320 million 
people. 

The EC and the European Free Trade 
Association, made up of Austria, Finland, 
Iceland, Norway, Sweden, and Switzer¬ 
land, are involved in cooperative efforts. 
There is a strong probability that ap¬ 
proaches taken by the EC will also be 
adopted by the EFTA. In addition, other 
countries have applied for EC member¬ 
ship, and more countries in Western and 


Eastern Europe are expected to be accept¬ 
ed into the common market in the future. 

As part of its efforts, the EC is estab¬ 
lishing systems for (1) product certifica¬ 
tion and (2) quality systems registration. 
These efforts directly affect manufactur¬ 
ers outside the EC who wish to do busi¬ 
ness within it. Simply put, the indica¬ 
tions are that companies outside the EC 
that manufacture EC-regulated products 
will not be permitted to market their 
products in EC countries unless 

(1) the products are certified to meet 
applicable EC standards, and 

(2) manufacture of the products is 
supported by a quality system that has 
been assessed and registered by a third- 
party organization acceptable to the EC 
as meeting appropriate standards. 


Moreover, although many products are 
not yet regulated by EC directives, an in¬ 
creasing number of European firms are 
refusing to buy or receive bids for non- 
regulated products from suppliers whose 
quality systems have not been registered 
as complying with ISO 9000 standards. 

The task of establishing European 
technical standards for products is in the 
hands of three standardization bodies: 

(1) The European Committee for Stan¬ 
dardization (CEN), which promotes Eu¬ 
ropean standardization in the nonelectro- 
technical field; 

(2) The European Committee for Elec¬ 
trotechnical Standardization 
(CENELEC), which covers the electro¬ 
technical field; and 

(3) The European Telecommunica¬ 
tions Standards Institute (ETSI), which 
promotes European standards for a uni¬ 
fied telecommunications system. 

These organizations are generating Eu¬ 
ropean standards in accordance with pri¬ 
orities established by the EC and its 
member states and in consultation with 
existing national standardization organi¬ 
zations. All member states are required 
to conform to each standard, once it is 
formally adopted. 

To avoid duplication of standards de¬ 
velopment at the European and interna¬ 
tional levels, CEN and CENELEC have 
negotiated agreements with the ISO and 
the International Electrotechnical Com¬ 
mission (IEC), respectively. CEN or 
CENELEC will only undertake a new 
standard when the standard does not ex¬ 
ist under ISO or IEC auspices or when 
the standard cannot be developed at the 
international level within a specific time 
frame. 

ISO standards for quality systems have 
been adopted by the EC. Table 1 lists ap¬ 
plicable ISO standards covering quality 
systems. 

Product certification. The impact of 
product certification is simple: Unless 
regulated products have been certified to 
meet EC requirements, they might be re¬ 
stricted from being sold in EC nations. 
Figure 1 lists some product groups regu¬ 
lated by EC essential-requirement direc- 


Table 1. ISO standards bearing on quality systems. 


Number 

Name 

ISO 8402 

Quality Vocabulary 

ISO 9000 

Quality Management and Quality Assurance Standards — 
Guidelines for Selection and Use (ANSI/ASQC Q90) 

ISO 9001 

Quality Systems — Model for Quality Assurance in Design/ 
Development, Production, Installation and Servicing 
(ANSI/ASQC Q91) 

ISO 9002 

Quality Systems — Model for Quality Assurance in 

Production and Installation (ANSI/ASQC Q92) 

ISO 9003 

Quality Systems — Model for Quality Assurance in Final 
Inspection and Test (ANSI/ASQC Q93) 

ISO 9004 

Quality Management and Quality System Elements — 
Guidelines (ANSI/ASQC Q94) 

ISO 10011-1 

Guidelines for Auditing Quality Systems — Part 1: Auditing 

ISO 10011-2 

Guidelines for Auditing Quality Systems — Part 2: 
Qualification Criteria for Auditors 

ISO 10011-3 

Guidelines for Auditing Quality Systems — Part 3: 

Managing Audit Programs 

ISO Guide 2 

General Terms and Their Definitions Concerning 
Standardization and Related Activities 

ISO/IEC Guide 39 

General Requirements for the Acceptance of Inspection 

Bodies 

ISO/IEC Guide 40 

General Requirements for the Acceptance of Certification 
Bodies 

ISO/IEC Guide 48 

Guidelines for Third-Party Assessment and Registration of a 
Supplier’s Quality System 


70 


COMPUTER 











tives for protecting health, safety, and the 
environment. In addition, products can be 
required to comply with additional stan¬ 
dards, such as those for radio interference, 
machine safety, and rollover protection. 

The American National Standards Insti¬ 
tute has been meeting with EC officials 
regarding establishing recognition for 
product certification in the US. 

Quality system registration. As I not¬ 
ed, in addition to certifying products, any 
firm supplying a regulated product will be 
required to have a quality system that has 
been assessed against the requirements of 
ISO 9000 standards. The reason for this is 
to assure maintenance of a consistent lev¬ 
el of quality. Quality systems that meet 
the standards will be registered as such. 

Current registration efforts. In Europe, 
the effort of assessing suppliers’ quality 
systems has already begun. More than 
10,000 British companies have been as¬ 
sessed and are registered in compliance 
with the ISO 9000 standards. In addition, 
more than 5,000 other companies are 
waiting to be assessed, according to an ar¬ 
ticle, “ISO 9000: A Management Perspec¬ 
tive,” by Ian F. Henday in the October 
1990 issue of the TAPPI Journal, pub¬ 
lished by the Technical Association of the 
Pulp and Paper Industry. 

Third-party evaluation. Quality system 
assessment, a third-party evaluation of a 
supplier’s quality system, determines if a 
particular system meets the requirements 
of the ISO 9000 series standards. Evalua¬ 
tions are carried out for two reasons: 

(1) So an organization that wanted to 
buy a product from a specific sup¬ 
plier will not need to expend un¬ 
necessary time and money to audit 
a specific supplier’s quality system 
and 

(2) So the supplier will not need to 
undergo a new assessment each 
time it wants to sell a product to a 
different customer. This is the 
point at which third-party assess¬ 
ment and registration difficulties 
might arise in non-EC countries. 

In Europe, third-party quality system 
assessment and registration activities are 
regulated by government agencies. The 
US doesn’t have a similar government- 
regulated process since industry stan¬ 
dards are developed by many nongovern¬ 
mental organizations, such as the IEEE, 
the American Society for Quality Con¬ 
trol, and the American Society of Me¬ 
chanical Engineers. 

This being the case, the ASQC has es¬ 
tablished a Registrar Accreditation Board 
(RAB) to develop a program to accredit 


organizations, called registrars. These 
registrars will assess supplier compliance 
with the appropriate quality-assurance 
standard in the ISO 9000 series. 

This assessment and registration pro¬ 
cess is designed to be compatible with 
the EC process (see Figure 2). The pilot 
phase of the RAB program for accredit¬ 
ing registrars is expected to be completed 
during the second quarter of 1991. Fol¬ 
lowing completion of a pilot phase, the 
RAB will consider applications for ac¬ 
creditation from potential registrars. 

The RAB organization. The Registrar 
Accreditation Board organization has a 
Board of Directors, an Accreditation 
Council, an Operations Council, and au¬ 
ditors, with the two councils reporting to 
the Board of Directors (see Figure 3). 

The Board of Directors develops poli¬ 
cy and long-range plans and oversees ac¬ 
creditation operations. The accreditation 
council reviews and evaluates informa¬ 
tion — including audit reports — about 
applicants for accreditation as registrars 
and grants or denies accreditation. The 
operations council develops and adminis¬ 
ters procedures for accreditation of regis¬ 
trars as well as procedures for qualifica¬ 
tion of auditors of registrars. 

The RAB process includes 

(1) Evaluation of the registrar’s docu¬ 
mented procedures (including its quality 


manual) as they compare with estab¬ 
lished criteria. 

(2) Assessment of the registrar’s per¬ 
formance compared to the registrar’s 
documented procedures. Assessment oc¬ 
curs at the registrar’s facility and during 
the registrar’s on-site assessment of a 
supplier’s quality system. 

(3) Independent evaluation of the reg¬ 
istrar’s assessment results. 

(4) Ongoing surveillance and periodic 
full reassessments of the registrar’s oper¬ 
ations. 

The RAB produces directory listings of 
accredited registrars and suppliers who 


Building products 
Gas appliances 

Lifting and loading equipment 
Medical devices 
Mobile machines 
Personal protection equipment 
Simple pressure vessels 
Small industrial trucks 
Telecommunication terminal 
equipment 
Toys 


Figure 1. Product groups regulated by 
EC directives. 



Glossary 


ANSI 

American National Standards Institute 

ASME 

American Society of Mechanical Engineers 

ASQC 

American Society for Quality Control 

CEN 

European Committee for Standardization 

CENELEC 

European Committee for Electrotechnical Standardization 

EC 

European Community 

EFTA 

European Free Trade Association 

EOTC 

European Organization for Testing and Certification 

ETSI 

European Telecommunications Standards Institute 

IEC 

International Electrotechnical Commission 

ISO 

International Organization for Standardization 

RAB 

Registrar Accreditation Board 
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UPDATE 


Stanford University takes programming prize 



Figure 3. Makeup of the Registrar Ac¬ 
creditation Board. 


have been registered by accredited regis- 

On the international level, the RAB has 
been working closely with the European 
Organization for Testing and Certification 
for mutual recognition of quality system 
registrations. (The EOTC is the EC orga¬ 
nization working toward mutual recogni¬ 
tion of quality system certificates and har¬ 
monizing procedures in EC and EFTA 
countries.) As a result, the RAB has been 
establishing an organization to represent 
the US in this effort and has the proce¬ 
dures in place. The pilot phase is provid¬ 
ing an opportunity to refine those proce¬ 
dures. 

On the national level, the RAB has 
been working with standards-making or¬ 
ganizations, private industry, and US gov¬ 
ernment agencies to provide a unified sys¬ 
tem in the United States for quality 
system registration that can be recognized 
throughout the world. 

Preparation is vital. In preparing for 
1992, it would be beneficial to review a 
quotation from Joe Paterno, the successful 
head football coach at Pennsylvania State 
University, as it relates to today’s Ameri¬ 
can business environment. “The will to 
win is important,” Paterno said, “but the 
will to prepare is crucial.” For US compa¬ 
nies who opt to pursue quality system reg¬ 
istration, doing so could be one of the 
most rewarding decisions they will make 
as they prepare for the unification of 
Western Europe in 1992. 


To go further 

Copies of ISO standards can be pur¬ 
chased from the ANSI, 1430 Broadway, 
New York, NY 10118, phone (212) 642- 
4900. 

A complete list and copies of the EC 
directives for regulated products can be 
obtained from the US Department of 
Commerce Office of European Communi¬ 
ty Affairs, Washington, DC, phone (202) 
377-5276. 


Twenty-five teams competed in the fi¬ 
nals of the 15th annual ACM Scholastic 
Programming Contest, with first, second, 
and third place going to Stanford Univer¬ 
sity, Vrije Universiteit (Netherlands), 
and Virginia Tech, respectively. 

Sponsored by AT&T Computer Sys¬ 
tems, the event featured teams from uni¬ 
versities in the US, Europe, Canada, and 
the Pacific Rim in a 5-hour battle of log¬ 
ic, strategy, and mental endurance. Each 
team had to create computer programs to 
solve as many real-life puzzles as possi¬ 
ble in the least amount of time and with 
the fewest number of attempts. 

Problems included routing fire trucks 
around closed streets, scheduling surgery 
patients through busy operating and re¬ 
covery rooms, and determining multiple 
ways to assign political districts. 

Contest finals, which took place 
March 6 in San Antonio, Texas, were 
conducted in a fully networked environ¬ 
ment using the Unix System V operating 
system. Students wrote problem solu¬ 
tions in their choice of Pascal or C. 


Microelectronics and Computer Tech¬ 
nology Corp., the Institute for Advanced 
Technology of the University of Texas at 
Austin, and Sandia National Laboratories 
have established a joint project to dem¬ 
onstrate the feasibility of using object- 
oriented technology to perform complex 
scientific simulations. 

The simulation program being devel¬ 
oped is a version of a production code 
called CTH. Sandia and other govern¬ 
ment contractors currently use CTH to 
perform complex simulations of the be¬ 
havior of solid materials struck by an ex¬ 
tremely high velocity projectile. 

“These simulations are incredibly 
complex and require extraordinary com¬ 
puting capability,” said Harry Fair, direc¬ 
tor of the Institute for Advanced Tech¬ 
nology. “Executing the simulations, even 


Teams finishing in fourth through 
sixth place were Victoria University of 
Wellington (New Zealand), the Universi¬ 
ty of Central Florida, and the University 
of Oregon. AT&T Computer Systems 
awarded a total of $25,000 in scholar¬ 
ships to the top six schools and donated 
AT&T 6386/25 Work Group System 
computers to the top four. 

AT&T Computer Systems sponsors 
the event to draw attention to the short¬ 
age of qualified software developers. 
“Our research shows that more than 60 
percent of computer science professors 
report no growth or a decline over the 
past three years in the number of com¬ 
puter science students enrolled in their 
departments,” said Curtis J. Crawford, 
the company’s vice president of sales, 
support, and service. “A full 40 percent 
of students we surveyed plan to pursue 
careers other than software development. 
Both findings underscore the fact that the 
well from which these much-needed pro¬ 
fessionals can be drawn is alarmingly 
shallow.” 


on large vector supercomputers, may 
consume tens to hundreds of hours.” 

Key to the new software is a function 
called an Object Manager, which in a 
parallel computer or network of worksta¬ 
tions handles the routine housekeeping 
functions required to allow software ob¬ 
jects to run in parallel, much as a presen¬ 
tation manager provides display house¬ 
keeping functions to programs in PCs 
and engineering workstations. 

In developing and testing the Object 
Manager software, MCC’s researchers 
discovered that the same software that al¬ 
lowed efficient use of a high-perfor¬ 
mance parallel processor could also turn 
a network of distributed processors into a 
very powerful parallel computer, even 
though multiple operating systems may 
be involved on the network. 


Project combines object-oriented technology, 
parallel processing 
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Scientists develop method to mass-produce 
semiconductor lasers 


Corbato receives 1990 
Turing Award 

Fernando J. Corbato, professor of 
computer science and engineering at the 
Massachusetts Institute of Technology, is 
the recipient of the ACM 1990 A.M. 
Turing Award. The award was presented 
March 5 at the ACM Computer Science 
Conference in San Antonio, Texas, to 
honor his work in formulating the con¬ 
cepts and leading development of both 
the Compatible Time-Sharing System 
and Multics (Multiplexed Information 
and Computer Service). 

Multics was a joint effort of Project 
MAC, Bell Telephone Laboratories, and 
General Electric. Honeywell later intro¬ 
duced Multics as a product. 

Corbato pioneered the development of 
computer operating systems. From 1960 
to 1965, he spearheaded both the devel¬ 
opment of CTSS at MIT’s Computation 
Center and Project MAC. CTSS was one 
of the first operating systems organized 
for utility-like use and the first to permit 
controlled sharing of files among users. 
Variants of Corbato’s multilevel proces¬ 
sor-scheduling algorithms are used in to¬ 
day’s time-sharing systems. 

An IEEE fellow and a member of the 
IEEE Computer Society, Corbato has 
previously been honored with the W. 
Wallace McDowell Award and the 
AFIPS Harry Goode Memorial Award 
for his development of time-sharing sys¬ 
tems. 

The Turing Award has been presented 
since 1966 by the ACM and includes a 
$25,000 prize provided by AT&T. 


Johns Hopkins University has 
launched a search for the best ideas, sys¬ 
tems, devices, and computer programs to 
help dissolve existing obstacles for the 
more than 25 million Americans with 
disabilities. A $10,000 grand prize will 
be awarded, as well as more than a hun¬ 
dred other prizes in regional competi¬ 
tions. 

Computer professionals, students, and 
amateurs are encouraged to enter in one 
or more of four major areas: employ¬ 
ment, independent living, education, and 
leisure. Contests will be held in each of 
10 federal US regions, with each section 
presenting a regional fair on December 7, 
1991, where award presentations will be 
made and winning inventions displayed. 


Scientists at IBM’s Zurich Research 
Laboratory report that they have devel¬ 
oped a way to fabricate up to 20,000 tiny 
lasers on a semiconductor chip. The de¬ 
velopment offers potential for the practi¬ 
cal and economic mass production and 
testing of semiconductor lasers for appli¬ 
cation in the optical storage of informa¬ 
tion on computer disks and fiber optic 
networks. 

The new method of laser fabrication, 
called “full-wafer technology,” should be 
faster, approximately 50 percent less ex¬ 
pensive, and yield a much higher per¬ 
centage of working lasers per wafer, 

IBM scientists say. The advancement 
holds promise for integration of the 
semiconductor lasers with other electron¬ 
ic components on optoelectronic chips 
that use both light and electric current. 

The semiconductor lasers are con¬ 
structed from crystals of aluminum galli¬ 
um arsenide. The crystals are grown us¬ 
ing standard “epitaxy,” which allows 
scientists to guide the crystal’s growth 
atomic layer by atomic layer and to con¬ 
trol its optical properties. Other ele¬ 
ments, or “dopants,” are added to the 
crystal as it’s grown to control its elec¬ 
tronic properties. The completed semi¬ 
conductor crystal wafer measures 2 inch¬ 
es in diameter. 

The laser mirrors are actually the sides 
of trenches etched into the semiconduc¬ 
tor crystal using photolithography. The 
process involves coating the crystal with 
a photosensitive material and then expos- 


Paul Hazan of Johns Hopkins’ Applied 
Physics Laboratory will lead the national 
search. He directed a similar program in 
1981 that yielded hundreds of inventions, 
many of which have become standard 
equipment for thousands of persons with 
disabilities. The search is being support¬ 
ed under a grant from the National Sci¬ 
ence Foundation and will be conducted 
in collaboration with leading rehabilita¬ 
tion, business, and professional organiza¬ 
tions. 

For information on submitting entries, 
write to Personal Computing to Assist 
Persons with Disabilities, PO Box 1200, 
Laurel, MD 20723. Entry deadline is Au¬ 
gust 23, 1991. 


ing a pattern for the trenches with a beam 
of ions. The walls of the trenches are 
within 80 atoms thickness of being per¬ 
fectly smooth. 

Previously, the mirrors were formed 
for each laser individually by “cleaving,” 
or breaking, the semiconductor crystal. 
The lasers then had to be tested individu¬ 
ally as well. But now IBM scientists 
have successfully used the etching pro¬ 
cess to fabricate and test thousands of la¬ 
sers at once on an uncut wafer. 

As electrical current passes through 
the aluminum gallium arsenide lasers, 
they emit light in the invisible, infrared 
range. The light ranges between 830 and 
850 nanometers, wavelengths used today 
for reading and writing optical data. 


ITU to offer on-line 
services 

The International Telecommunication 
Union is in the first phase of an opera¬ 
tion designed to enable partners of the 
world telecommunication community to 
obtain the most up-to-date ITU-related 
information and to exchange information 
and data with union headquarters. 

The Telecom Information Exchange 
Services, to be implemented gradually, 
will offer facilities such as electronic 
mail, bulletin boards, document inter¬ 
change, computer conferencing, distrib¬ 
uted access to ITU databases, and notifi¬ 
cation of telecommunication 
information, including a terminology in¬ 
formation base of 30,000 telecommuni¬ 
cations terms in English, French, and 
Spanish. 

The system will be accessible through 
public telecommunication networks 24 
hours a day, seven days a week. Potential 
users include telecommunication authori¬ 
ties in the union’s 164 member countries, 
recognized private operating agencies, 
industrial and regional organizations, and 
telecommunication users throughout the 
world. 

To complement the Geneva-based sys¬ 
tem, regional and national hosts as well 
as access paths and gateways are needed. 
Hosts or gateways might be sponsored by 
regional or national standards bodies, in¬ 
dustry associations, or telecommunica¬ 
tion service providers. 

Inquiries can be directed to the Inter¬ 
national Telecommunication Union, 

Place des Nations, CH-1211 Geneva 20, 
Switzerland, phone 41 (22) 730-5111. 


Computer competition to aid persons 
with disabilities 
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Heart attack claims life of Fernbach 


IEEE Computer Society officers, vol¬ 
unteers, and staff were saddened to learn 
that veteran Compcon Spring Steering 
Committee Chair and supercomputing pi¬ 
oneer Sidney Fernbach succumbed to a 
heart attack in February. According to 
long-time friend and fellow Computer 
Society volunteer Rex Rice, Fernbach’s 
death marked “the passing of an era.” 

In addition to his years of work on be¬ 
half of Compcon Spring, Fernbach was 
active in the annual Supercomputing 
conference and served briefly on the 
Computer Society’s Board of Governors. 
In 1983 the society honored him with the 
Richard E. Merwin Award for Distin¬ 
guished Service. 

Fernbach spent most of his career with 
Lawrence Livermore National Laborato¬ 
ry. Under his direction the computation 
department grew from a small Univac I 
facility in the early fifties to become one 
of the largest computer facilities in the 
world. During his last years at Liver¬ 
more, he was deputy associate director 
for scientific support. After retiring in 
1979, he worked as an independent con¬ 
sultant, maintaining a long-term consult¬ 
ing relationship with Control Data Corp. 

Fernbach received the 1987 W. Wal- 



Sid Fernbach 


lace McDowell Award for “continuously 
challenging, inspiring, and supporting 
American designers and industry to pro¬ 
duce many successive generations of su¬ 
percomputers.” 

For several years he chaired the IEEE 
Scientific Supercomputer Subcommittee, 
a technology-policy committee under the 
IEEE United States Activities Board. 

The subcommittee produced a number of 
position papers on supercomputers. 


At its March 1 meeting, the IEEE 
Computer Society’s Board of Governors 
nominated Bill D. Carroll and Gerald L. 
Engel for the position of 1992-1994 
IEEE Division V delegate-director. 

These candidates will be on the IEEE 
ballot for the fall 1991 election. 

Carroll is a member of the Computer 
Society’s Educational Activities Board 
and serves as chair of the IEEE Commit¬ 
tee on Engineering Accreditation Activi¬ 
ties. A former member of the society’s 
Board of Governors, he also served as 
editor-in-chief of the Computer Society 
Press. Carroll has been both a professor 
and the department chair for the Comput¬ 
er Science Engineering Department at 
the University of Texas at Arlington 
since 1981. 

Engel is the society’s vice president 
for Area Activities and previously served 
two terms as vice president for Educa¬ 
tion. He was active in development of 
the Computing Sciences Accreditation 
Board and is working with a Computer 
Society-ACM joint task force to develop 
a new model program in computer sci¬ 
ence and engineering. Engel is interim 
director for the University of Connecti¬ 
cut’s Waterbury Regional Campus. 

Additional candidates may be nomi¬ 
nated by petition. Completed petitions 


A fellow of the American Physical So¬ 
ciety and the American Association for 
the Advancement of Science, he was also 
a member of the National Science Foun¬ 
dation’s Steering Committee on Compu¬ 
tational Science and Engineering Re¬ 
search Study and a senior member of the 
IEEE. 

Fernbach earned a PhD in theoretical 
physics from the University of California 
at Berkeley in 1952. 


must be submitted in a letter to the Board 
of Directors and be received at IEEE 
Headquarters by noon on May 31. The 
minimum number of signatures must in¬ 
clude at least 1 percent of the voting 
members of the division, provided that a 
majority of the societies in the division 
are represented on the petition by at least 
1 percent of their voting members. 

For additional information on nomi¬ 
nating petitions, contact Mercy Kowal- 
czyk at IEEE Headquarters, 345 E. 47th 
St., New York, NY 10017. 


Task force solicits 
participation 

The IEEE Computer Society’s recently 
created Task Force on Parallel Process¬ 
ing invites comments and suggestions 
from practitioners interested in the vari¬ 
ous aspects of parallel processing sys¬ 
tems. Contact the task force chair, V.K. 
Prasanna Kumar, Department of Electri¬ 
cal Engineering Systems, EEB-244, Uni¬ 
versity of Southern California, Los An¬ 
geles, CA 90089-2562, e-mail 
prasanna@ashoka.usc.edu. 


Carroll, Engel nominated for delegate-director 
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GENERAL CHAIRS 


CALL FOR PAPERS AND PARTICIPATION 


Asoke K. Laha 

Cadence Design Systems, Inc. 

Systems Division 
2 Lowell Research Center Dr. 

Lowell, MA 01852-4995, USA 
(508) 934-0233, 441-1109 (FAX) 
laha@ cadence.com 
Lalit M. Patnaik 
Comp. Sci. & Automation 
Indian Inst, of Science 
Banglore 560012, India 
(0812) 342451 
lalit%vigyan@ shakli.cmet.in 
ORGANIZING COMM. CHAIR 
G. H. Visweswara 
Indian Telephone Industries 
PROGRAM CHAIRS 
Yashwant K. Malaiya 
Computer Sci. Dept 
Colorado State Univ. 

Ft. Collins, CO 80523, USA 
(303) 491-7031, 491-2293 (FAX) 
malaiya@ravi.cs.colostate.edu 
K.S. Raghunathan 
Microelect. & Comp. Div. 

Indian Telephone Industries 
Banglore 560016, India 

(812) 563211, 572824 (FAX) 
TUTORIALS CHAIRS 
Debashis Roy Chowdhury 
Gateway Design Auto. (India) Pvt. Ltd. 
SDF#A-1, NOIDA export processing zone 
P.O. NEPZ, NOIDA 201305, U.P., India 
(05736) 62340, (05736) 62231 (FAX) 
debashis@cadence.com 

Simon Curry 

Bell Northern Research 

PO Box 3511, Station C 

Ottawa, Ontario, Canada 

(613)763-2981,7241 (FAX) 

curry@bnr.ca 

PUBLICITY CHAIRS 

N. Ranganathan 

Dept, of Comp. Sci. & Eng. 

Univ. of South Florida (ENG 118) 

Tampa. FL 33620, USA 

(813) 974-4760, 5456 (FAX) 
ranganat@ sol.csee.usf.edu 
Jaswinder S. Ahuja 

Gateway Design Auto. (India) Pvt. Ltd. 

SDF#A-1, Noida Export Processing Zone 

P.O. NEPZ, Noida 201305, U.P., India 

(05736) 62340 (05736) 62231 (FAX) 

jassi@cadence.com 

PUBLICATION CHAIR 

Srimat T. Chakradhar 

NEC Research Institute 

4 Independence Way 

Princeton, New Jersey 08540 

(609) 951-2962, 2499 (FAX) 

chak@research.nec.com 

PAST CHAIRS 
Vishwani D. Agrawal 
AT&T Bell Labs 
A. Prabhakar 
Indian Telephone Industries 


VLSI DESIGN ’92 

THE FIFTH 

INTERNATIONAL CONFERENCE 
ON VLSI DESIGN 


Bangalore, India 
January 4-7, 1992 


In Cooperation with: 


m 

4 


IEEE COMPUTER SOCIETY 

Technical Committees on Design Automation and VLSI 

IEEE CIRCUITS AND SYSTEMS SOCIETY 

THE INSTITUTE OF ELECTRICAL 
AND ELECTRONICS ENGINEERS, INC. 


Sponsored by: 



VLSI SOCIETY OF INDIA (VSI) 

DEPARTMENT OF ELECTRONICS (GOVERNMENT OF INDIA) 


The conference is a forum for researchers and designers to present and discuss various 
aspects of VLSI design. The four-day program will consist of regular paper sessions, 
posters, tutorials, and industrial CAD exhibits. There will be opportunities for informal 
exchange of ideas. The proceedings will be published by the IEEE Computer Society. 


TOPICS OF INTEREST: CAE/CAD Systems, High Level Synthesis, Logic Synthesis, 
Fault Modeling, Test Generation, Design For Testability, Layout, Routing, Logic Simula¬ 
tion, Circuit Simulation, Timing Verification, Application Specific Devices, Microarchi¬ 
tecture, Regional/Global Perspectives, Economic Issues, etc. 


PAPERS: Six copies of previously unpublished papers should reach either program 
chair by June 1, 1991. A manuscript should clearly, state the original contribution, 
significant results and applications. It should not exceed ten double-spaced pages 
including figures and references. The authors should identify the presenting author and 
include the complete address, telephone and/or FAX numbers and, when possible, email 
address. The papers will be selected through a review process and the authors will be 
notified of acceptance by August 1, 1991. The camera-ready manuscripts must reach the 
publication chair by September 15, 1991. 


TUTORIALS: The symposium has run a highly successful tutorials program in the past. 
This year, four full-day tutorials are planned. The topics for the tutorials are open and 
include analog VLSI design, synthesis, formal verification, hardware description 
languages, distributed algorithms for VLSI CAD, CAD framework, and tools and design 
methodology for VLSI design in India. Proposals may be submitted to either of the 
tutorials chairs by June 30, 1991. A tutorial may include a software demonstration. 


EXHIBITS: The symposium provides a unique opportunity to CAD/CAE system ven¬ 
dors to display their products to the attendees. Since the available space may be limited, 
those interested should contact the general chair as soon as possible. 


AWARDS: A best paper award (Prof. A.K. Choudhury Award) of Rs. 10,000 and two 
other honorable mention awards of Rs. 2,000 will be given. In addition a design contest 
is planned. Those interested in the design contest should contact the publicity chair. 

For any other information concerning the symposium contact publicity chairs. 







NEW PRODUCTS 


Contact or send releases to Christine Miller, Computer, 10662 Los Vaqueros Circle, PO Box 3014, Los Alamitos, CA 90720-1264; Compmail s.c.miller. 


SCSI peripheral installs 
like a disk drive 

Gradient Technology’s Desk Lab for 
voice, acoustic, and other data-acquisi- 
tion and playback tasks features real¬ 
time capability for Unix and VMS work¬ 
stations. The workstation peripheral 
requires no special software drivers. 


Users control data acquisition and 
playback directly from the Unix/VMS 
command line or from user programs that 
call Desk Lab’s C-function library. Users 
can also create complete applications 
from shell scripts. 

A graphics package with zooming, cut 
and paste between files, playback param¬ 
eter control, and selected statistics com¬ 
putation supports signal analysis and 
playback. 

Optional integral 
floppy and SCSI hard 
disks enhance flexibil¬ 
ity and provide stand¬ 
alone operation. 

Desk Lab costs 
$5,500. 

Reader Service 36 



Desk Lab provides 
Unix and VMS work¬ 
stations with data- 
acquisition functions. 


Scientific software 
upgraded 

Minsq, a PC program for general curve 
fitting, model development, and parame¬ 
ter estimation, enables users to plot equa¬ 
tions and develop formulas describing 
chemical, electronic, and mechanical re¬ 
lationships. 

Version 4.0 from Micro Math Scientif¬ 
ic features extended, expanded, or swap- 
file memory support. Version 4.0 also 
lets users assign weights to individual 
points, add error bars and label annota¬ 
tion to plots, and perform multiple y-axis 
plotting. 

Encapsulated Postscript output adds 
flexibility to word processing and page- 
layout software. 

Upgrades cost $99 and single-user 
copies are $249. 

Reader Service 35 


C scientific library for IBM 
RISC/6000 

The HAAR numerical C library fea¬ 
tures a scientific array of algorithms. Ac¬ 
cording to the company, the library is 
equivalent in power and accuracy to For¬ 
tran mainframe libraries. 

Included are basic linear algebra rou¬ 
tines, matrix decompositions, eigensys- 
tem analyses, spline routines, interpola¬ 
tions, and differential equations. 

The data-fitting routines include para¬ 
metric splines, splines under tension, ro¬ 
bust data, least squares, and minimax 
procedures. 

The base price for an IBM RS 6000- 
320 single user is $1,295, with increases 
for multiuser systems. The library is also 
available for other workstation plat¬ 
forms. 
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DAT drive option offers 
tape backup for Compaqs 

Digital audio tape (DAT) drive options 
from Compaq store up to 4 Gbytes of 
memory on 2 x 3-in. tape cartridges at a 
rate of up to 11 Mbytes/min. 

The DAT drive option supports 1.3- 
and 2.0-Gbyte standard removable tape 
cartridges. A 1.3-Gbyte tape cartridge 
and a SCSI compression adapter board 
come with the drive. 

The 16-bit board with EISA direct- 
memory access can double storage ca¬ 
pacity. Users can install two drives into 
most Compaq models. 

Operating system support includes Mi¬ 
crosoft OS/2, MS-DOS, Novell Net Ware 
286/386, and SCO Unix. 

The option sells for $5,499. 


Array storage system 
supports advanced systems 

The Intelligent Array Expansion Sys¬ 
tem for Compaq System Pro comes with 
a 32-bit expansion controller. The expan¬ 
sion unit is designed for advanced con¬ 
nected environments with storage-inten¬ 
sive applications. 

The system features 2.6-Gbyte fixed- 
disk drive array storage and can be 
scaled up to 9.1 Gbytes. By adding two 
expansion systems. System Pro users can 
increase storage capacity to almost 20 
Gbytes. 

Offered are user-selectable fault-toler¬ 
ant features such as drive mirroring, an 
on-line spare drive, and controller du¬ 
plexing. 

The expansion system supports Novell 
Net Ware 386 and SCO Unix System V. 

The cost is $21,999 for the base sys¬ 
tem. Additional 1.3-Gbyte drives are 
$9,099; additional intelligent drive-array 
expansion controllers (for duplexing) are 
$2,999. 
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Windows Windows Windows Windows Windows Windows 



Database management 
system 


Malachite Corp.’s Dossier for Win¬ 
dows, a multiuser relational database 
system, runs under Microsoft Windows 
3.0 and is compatible with dBase and 
Clipper database applications. 

The software features a multiple-doc¬ 
ument interface and a file browser that 
lets the user customize displayed data 
columns. Dossier for Windows also pro¬ 
vides a built-in dialogue-box editor to 
create database record-editing windows 
and attaches program code to any data 
field or Windows control, such as push 
buttons. This feature enables users to fo¬ 
cus on one aspect of the application 
without rebuilding the system. 

The package costs $495 (demonstra¬ 
tion disks available). 
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OCR upgrade 


Nisca Inc. has added Ocron’s Per¬ 
ceive Personal optical character recogni¬ 
tion software to its OCR for Windows 
software. The package runs on IBM AT 
286/3 86s with 2 Mbytes of memory and 
on PS/2 Models 25 and 30. 

The Windows 3.0-compatible Niscan/ 
GS OCR Version 2 includes true omni¬ 
font capabilities, requiring no character 
training. According to the company, 
Perceive features a 99 percent accura¬ 
cy rate and a 50-to-150 characters-per- 
second recognition rate. Typefaces from 
8 to 36 points are recognized. 

Users can select a region of text and 
manipulate it by using the shift and ar¬ 
row keys. 

Text recognized with this package can 
be downloaded in ASCII and ANSI for¬ 
mats and into Word Star and Word Per¬ 
fect, with or without carriage returns. 
Image file formats include .IMG, .TIF 
(compressed and uncompressed), .PCX, 
Microsoft Paint formats (l.xx and 2.xx), 
Mac Paint, and Eye Star. 

The redesigned package retails for 
$599. 
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Mature VAX Stations 

Vaxeln Window Server software from 
DEC installs in VAX workstations over 
an Ethernet local area network and pro¬ 
vides users with the same functions as 
DEC’S VT1300 window terminal. 

The software enables users to simulta¬ 
neously access multiple hosts using 
DECnet or transmission control/Intemet 
protocol networking software. 


Scientific image processing 

Data Translation has introduced Global 
Lab Image, an image-processing and analy¬ 
sis package for scientific and engineering 
applications on the IBM PC AT and the 
PS/2 frame-grabber boards. 

Functions include automatic object 
counting and measurement, frequency anal¬ 
ysis, and spectrum editing. 

The Windows 3.0 environment allows 
data exchange between Global Lab Image 
and other programs for analysis or report 


The window server supports VAX 
models 2000, VAX Station 11/3500, as 
well as the newer 3100/3500. Applica¬ 
tions can run under VMS or Ultrix op¬ 
erating systems. 

The cost is $570 per station and $310 
for the media kit on the host system. 
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generation. An advanced scripting facility 
can be used to customize applications. 

The package, which comes on 5.25-in. 
and 3.5-in. disks, supports morphology, fil¬ 
ters, arithmetic and logic operations, histo¬ 
grams, overlays, image acquisition, and 
display. 

The cost for the system is $2,495. Ship¬ 
ments begin April 15. 
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Global Lab Image combines features of Microsoft Windows 3.0, object count¬ 
ing and measurement, frequency analysis, filtering, and image-acquisition dis¬ 
play. 
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Common Lisp developer 

Golden Common Lisp Developer 4.0 
from Gold Hill is fully integrated with 
the Microsoft Windows 3.0 environ¬ 
ment. The foreign-function interface al¬ 
lows calls back and forth between Lisp 
and other programming environments, 
such as C. Dynamic data exchange en- 


Interface development tool 

Xvt Software Inc. has introduced 
Open Look for the Extensible Virtual 
Toolkit, a graphical user interface de¬ 
velopment tool that provides source 
code portability across dissimilar win¬ 
dow systems. Open Look offers com¬ 
patibility with Sun Microsystems’ Open 
Window environment. 

The roster of Xvt-supported window 
systems includes OSF/Motif for the 
X Window System, Microsoft Win- 


Object-linkable library 

Drover’s Toolbox for Windows 1.2 
is a dynamic object-linkable library for 
use in Windows 3.0 application devel¬ 
opment. 

The toolkit contains more than 200 
functions, including a pop-up annual 
calender for date input, an analog/digi¬ 
tal gauge for data display, and a pattern 
editor for graphics. A utility creates 
new shell applications with a single 
command. 

One library contains utilities for en¬ 


ables data transfer to databases, spread¬ 
sheets, and other existing programs. 

The developer supports Portable 
Common Loops, an object-oriented 
programming system. 
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dows. Presentation Manager for OS/2 
and CTOS, Macintosh, and character- 
based displays. 

Xvt identical application source code 
runs on all platforms and looks native 
on each. The toolkit also supports C 
and C++ programming languages. 

Open Look for Sun Sparc worksta¬ 
tions will ship in May. 
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ror handling and message boxes with a 
set of classes for windows. Another li¬ 
brary includes dialogues for a printer 
setup, opening files, page setup, and 
status. The toolkit comes with a modi¬ 
fied version of C runtime library. A 
sample application is included. 

Toolbox for Windows costs $295. A 
source code option is available for 
$885. 
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Object-oriented image processing 


Krig Research has introduced an 
image processing system with object- 
oriented features and parallel processing. 

Picture Center features an X/Motif in¬ 
terface that runs on most major worksta¬ 
tion platforms. Automatic parallel pro¬ 
cessing allows users to increase 
performance by running the software on 
multiprocessor workstations. 

The system supports gray-scale and 
color images. Supported data formats in¬ 
clude integer, floating point, and 24-bit 


true color. The system operates on both 
data objects and process objects. 

The user interface can be customized, 
with user code added to the system. 

Other features include draw, paint, 
graphics, and bitmap editing, a user- 
programmable expert system, and statis¬ 
tical analysis. Optional hardware inter¬ 
faces include gray-scale and color frame 
grabbers and flatbed scanners. 
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Pen-based computing 
arrives 

Go Corp. has released the developer 
version of Pen Point, an operating system 
that uses a pen instead of a keyboard or 
mouse. 

Pen Point features an interface that lets 
users interact with documents through a 
table of contents. The interface recog¬ 
nizes handwriting in printed uppercase 
and lowercase letters and responds to 
pen-generated commands (called ges¬ 
tures) such as writing an X to delete 
material. 

The system recognizes at least 20 pun- 
cutation symbols and computes letter and 
word spacing. Users need not write a 
special space character or write within 
boxes 

An embedded document architecture 
lets users combine data types within the 
same document by embedding one docu¬ 
ment inside another. A simple gesture 
can create a hyperlink button. 

Users correct spelling errors by 
tapping on the correct word in a list or 
writing over one or two characters. The 
company claims a high level of word- 
recognition accuracy. 

Envisioned applications include field 
engineering, mathematics, document 
markup and revision, graphics/drawing, 
and electronic notetaking. 

Borland International, Lotus Develop¬ 
ment, Word Perfect Corp., and Nestor 
are among the 40 companies currently 
developing or providing technology for 
Pen Point. 
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Application development 
system from Slate Corp. 

The Pen Apps application development 
system for the Pen Point operating system 
allows users to read from and write to 
existing database formats through an open 
architecture. 

A deferred translation feature lets users 
take down information in their own hand¬ 
writing and perform translation later. Intel¬ 
ligent input targeting also helps them stay 
within the lines. 

Users can draw a form-oriented interface 
and specify the types and locations of the 
fields. They can also use a “filler” to create 
new forms, fill them out, or navigate through 
existing forms. 

The Pen Apps Developer’s Release is 
$2,500. 
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The Fault-Tolerant Computing Symposium 

has become the major international forum 
in all aspects of fault-tolerant computing, 
such as: specification, design, implementa¬ 
tion, test, diagnosis and evaluation of 
dependable and fault-tolerant computing 
systems. The scope of the symposium 
spans hardware, software and system 
issues. 

Major topics include, but are not limited 
to: fault-tolerance in real-time systems, 
certification of safety-critical systems, 
software fault tolerance, fault recovery 
in transaction-processing systems, data 
security and integrity, fault tolerance in 
communication networks, validation of 
VLSI designs and implementations, testing 
and defect tolerance. 


Important Information: 


Advance Registration 

Canadian Dollars 

FTCS-21 Registration 

May 15,1991 


c/o Prof. Janusz Rajski 

Member IEEE 

$375 

McGill University 

Non-Member 

$475 

Dept, of Electrical Engineering 

Student 

$100 

3480 University St., Room 633 

At Conference Registration 


Montreal, CANADA H3A2A7 

After May 15,1991 


FAX: (514)398-4470 

Member IEEE 

$450 

email: rajski@spock.ee.mcgill.c 

Non-Member 

$550 


Student 

$125 



About Montreal: 

Montreal, founded in 1642, is the only 
French metropolis in North America, 
and is the second-largest French city 
in the world after Paris. Located on 
an island in the narrows of the St 
Lawrence river, with a population of 
some 2 million, Montreal offers visitors 
a unique blend of American and 
European culture, with a "down home" 
flavour rooted in a rich folk tradition. 

Symposium participants are invited 
to extend their visit for a few days to 
catch the Montreal International Jazz 
Festival, prowl the cobbled streets of 
Old Montreal, or just lounge in a bistro 
on rue St-Denis. Experience a city with 
a difference. 


Ex-officio member: 

H. Kopetz, TC chairman 
TU Vienna, Austria 
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1C Announcements 


Company, Model, Function Comments R.S. No. 


Analog Devices 
AD9950 

Phase accumulator 


AMP 

Micropitch 

Sockets 


Daico Industries 
DA0887 
GaAs attenuator 


Fujitsu 

MB88346 

DAC 


Fujitsu 
ET2600VH 
ECL array 


Accommodates direct digital-synthesis frequencies of 30 to 130 MHz and features bipolar tech- 120 

nology. Requires 5 V and— 5.2 V supplies and consumes 1.5W. Requires no heat sinking. Comes in 
68-pin J-lead ceramic chip carrier and in commericial (0° to 70°C) and military (-55° to 125°C) 
versions. Cost (100s): starts at $99.95 for commercial version (samples available). 

Accommodate National Semiconductor chips for fiber-distributed data-interface network 121 

applications. Two-piece sockets for PQFPs feature 0.25-in. contact centerline spacing and a 
0.375-in. maximum profile above printed circuit board. Optional cover assembly available. Low- 
profile PLCC sockets feature 0.185-in.-high housing. Cost (1,000s): $0.07 per line (cover); $0.08 
per line (socket); (10,000s) $0,003 to $.044, low-profile version. 

The 7-bit attentuator features broadband operating frequency of 20 to 1,000 MHz. Uses MMICs 122 

and thin-film hybrid technology in a hermetic 38-pin DIP package. Provides an attenuation range 
from 0 to 63.5 dB with a 0.5-dB LSB. Features an integrated TTL driver and DC blocking cap¬ 
acitors and operates at a temperature range from-55 C to 125 C. Options include military screening. 

No price given. 

Designed for 4- and 8-bit microcontrollers, runs at 2.5 MHz and features 12-channel, 8-bit 123 

buffered output operation. Individual channel units input digital data. Converter requries 5 V 
power supply, consumes 250 mW, and functions in temperature range of-20° to 85°C. 

Comes packaged in 20-pin DIP and SOJ plastic flatpacks. Cost (1,000s): $4.50. 

Gate array line designed for telecommunications and instrumentation offers a gate count of2,544 124 

with an operating frequency of 1 -GHz input and 650-MHz output. Provides ECL and TTL interface 
capabilities. Runs at 75 or 90 ps, depending on cell power. Power dissipation is 5W. Comes packaged 
in 124-pin quad flatpacks. Cost (large quantities): $98.00. 


Information Storage 

Devices 

ISDIOxx 

Voice storage chips 


LSI Logic 
Fastest 

Array technology 


MIPS Computer 

Systems 

R4000 

Microprocessor 

SEEQ Technology 

28HC256 

EEPROM 


SP9490 

ADC 


Texas Instruments/ 

Hitachi 

DRAM 


Combine analog signal conditioning and digital control functions in voice/music recording, 125 

storage, and playback subsystem. Store sampled analog voltages at up to 10,000/sec. Require 
a microphone, speaker, 5 V power source, and passive components for complete system. Zero- 
power memory retention exceeds 10 years. Available in 12-, 16-, and 20-sec. versions with pass 
bands of 4.5,3.4, and 2.7 kHz. Come in 28-pin DIP, PLCC, or SO packages. Cost (1,000s): 
from $15.00. 

Devices eliminate test development requirement in array-based application-specific IC design, 126 
which cuts design time in half. Provide fault coverage of about 98 percent. Embedded test structures 
provide observation points at every design node, eliminating circuit performance loss. No price 
given. 

Single-chip 64-bit microprocessor transitions from 32 to 64 bits. Features superpipelining, 127 

which allows the computer to issue two instructions per clock cycle. Includes integer and floating¬ 
point processing units, an 8-Kbyte data cache, cache control, a memory management unit, and 
full multiprocessing capabilities. No price given. Available mid-year 1991. 

Listed on standard military drawing 5962-88634 for electrical and processing requirements. 128 

Features access time of 90 or 120 ns and a write time of 3 or 10 ms. Access time of 70 ns is 
available. Provides current requirement of 60 mA with a standby current of 300 |lA. Comes in flat- 
pack, DIP, and LCC. Cost (100s): $288. 

Converter provides 1 -MHz sampling/throughput rate with 2.75W power dissipation. Features a 129 

90-dB spurious-free dynamic range, 87-dB SNR, and 85-db SIN AD. Accommodates ±5 V or+lOV 
bipolar or 0V to 10V unipolar. Performs 16-bit conversion in 700 ns. Temperature ranges from 
-55°C to 125°C. Cost (100s): $735. 

Houses chips as large as 330 x 660 mils, minimizes on-chip noise, and makes the electrical 130 

characteristics of the leads more uniform. Lead frame design features leads that are equal distance 
from each other and equal length. External package meets JEDEC standards. Features 28/24-pin 
lead-on-chip with center bond, plastic SOJ. No price given 
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Microsystem Announcements 


Company, Model, Function Comments R.S. No. 


Alligator Technologies 
AAF-1 

Antialias filter 


Apple Computer 
“Plug and Play” 
Ethernet products 


Ariel 

DTK-300 

Development system 


Intelligent Interfaces 
Memory board for 
HP 340 computers 

Interaction Systems 
Model 5100 

Touch-screen controller 


Micro Way 
Fast Cache-SX/Plus 
AT accelerator 


Planar 
EL7768MS 
EL display 


Real Time Devices 
ADA2100 
ADA interface 


S AI Systems 
Pee Wee 

Transportable PC 


Specialty Development 
US83C87 

Numeric coprocessor 


StarMicronics 
Laser Printer 4 


Trend Micro Devices 

PC-cillan 

Virus protector 


Antialias board for analog-to-digital systems handles two to eight differential channels per half 135 

board with no limit on the number of boards per system. Daughterboards provide a selection of low- 
pass filters. Bessel, Butterworth, and Cauer (eliptic or brick wall) filters are available. Complete 
two-channel filter system includes board, cable, and calibration software. Cost: $981. 

Networking product family includes the Ethernet LC Card for the Macintosh LC computer, the 136 

Ethernet NB Card for Nubus-based Macintosh II computers, and three media adapters to connect 
the cards to any industry-standard Ethernet media. Products comply with IEEE 802.3 standards. 

Cost: LC Card, $ 199; NB Card, $424; Thin Coax Transceiver, $175; AUI Adapter, $175; Twisted- 
Pair T ranscei ver, $175. 

Development system for Motorola’s 24-bit DSP56001 digital-signal-processing chip is designed 137 

for Hewlett-Packard 900 Series 200/300 engineering workstations. The DTK-300 occupies a 
single slot in the computer; it features versatile digital inputs and outputs and comprehensive DSP 
development software. Cost: $4,995. 

Micro RAM 340 is a 4-Mbyte memory expansion board designed for the new Hewlett-Packard 340 138 

computers. Board comes with complete documentation, a 90-day money-back guarantee, and a 
two-year warranty. If required, 24-hour service is standard. Cost: $ 1,995. 

Because the 5100 stand-alone controller resides outside the display housing, it simplifies touch- 139 

screen implementation, particularly for small-screen displays where size limitations prohibit 
additional electronics in the display enclosure. The controller is compatible with a wide variety of 
CRTs, monitors, and flat panel displays. No price given. 

This 16- or 20-MHz 386SX accelerator is a full-length expansion card that converts the IBM AT 140 

or compatible into a 386SX with up to 8 Mbytes of extended memory, enabling AT owners to run 
32-bit protected-mode applications and multitasking operating environments such as Windows 3.0. 

Cost: $595 (16-MHz version); $695 (20-MHz version). 

Electroluminescent display — an alternative to liquid-crystal and plasma displays — is light emit- 141 

ting and viewable in indoor, outdoor, and high-ambient light conditions. It supports all IBM VGA 
modes with 16 gray-scale levels, is timing and pin compatible with the feature connector on XT/AT 
VGA boards, and uses typical TTL video signals. Cost (in quantities): about $700. 

PC-bus data-acquisition interface is a short-slot card that offers 12-bit A/D and D/A conversion, 142 

digital I/O, and timing capabilities. Accompanying disk of sample programs illustrates control in 
Basic, Turbo Pascal, Turbo C, and assembly language. The device is compatible with RTD’s Atlan¬ 
tis series data-acquisition software. Cost: $395. 

System measures 1 3/4 X 10X8 inches and weighs 4.9 pounds. Based on the Intel 80286 12-MHz 143 
CPU, the system has a built-in 100V/220V switching power supply, 1 Mbyte of on-board memory 
(expandable to 2 Mbytes), and 40-Mbyte hard drive (expandable to 200 Mbytes). Color monitors 
with VGA and Mono VGA are optional. Cost: $ 1,095 (with 40-Mbyte drive, monochrome monitor, 
and keyboard). 

A plug-compatible alternative to the Intel 80387DX coprocessor, the US83C87 outperformed the 144 
Intel part in benchmark testing, according to its manufacturer. It supports all data types, registers, 
instructions, and interrupts specifically designed to facilitate high-speed numerics processing and 
conforms to the IEEE 754-1985 floating-point standard. Cost: $779 (33-MHz version). 

Laser printer for small businesses and home offices features 151 fonts, 1-Mbyte standard memory, 145 

four-pages-per-minute printing speed, high-speed throughput of complex graphics, and full com¬ 
patibility with Hewlett-Packard’s Laserjet IIP. Standard interfaces include a Centronics parallel and 
RS-232C serial for use with IBM and Apple computers. No price given. 

Comprehensive antiviral protection system immunizes MS-DOS and LAN computer systems 146 

against known and future viruses and provides hardware protection against boot-sector viruses. It 
transforms viral characteristics into a rule base for 12 intelligent viral traps that seek and identify 
viruses without false alarms or frequent updates. No price given. 
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PRODUCT REVIEWS 


Editor: Richard Eckhouse, UMASS-Boston, Harbor Campus, Boston, MA 02125, Compmail, r. eckhouse; Bitnet, eckhouse@cs.umbsky. 


How much handheld can a hand hold? 

Quentin Fennessy, ITP Systems 


I bought my first calculator more than 
15 years ago — and was I impressed! The 
Novus 650 had six digits of precision and 
two fixed decimal places. It performed 
addition, subtraction, multiplication, and 
division. And it did all this in something 
called reverse Polish notation (the oper¬ 
ands are entered before the operators). I 
paid about $15 for it (several weeks wag¬ 
es for a paperboy). 

Ever since then I have indulged my fas¬ 
cination (in fits and starts) with calcula¬ 
tors and computers. The last calculator I 
purchased does symbolic calculus and 
matrix manipulation, and plots equations 
on the screen. 

The purpose of this review is to give 
you an idea of what you will find in to¬ 
day’s hand-held computers. I discuss five 
machines: the Hewlett-Packard HP48SX, 


Hewlett-Packard 48SX 

The 48SX is a hand-held computer 
masquerading as a pocket calculator. It 
measures about 18x8x3 cm and 
weighs 264 grams. Its traditional calcu¬ 
lator form factor has 49 multifunctional 
keys and an eight-line-by-22-character 
(or 131 x 64-pixel), high-contrast LCD. 
Displayed menus are activated through 
six function keys that allow entry of al¬ 
phanumeric characters, mathematical 
symbols, and punctuation. 

The HP48SX comes with 32 Kbytes 
of RAM and 256 Kbytes of ROM. The 
memory can be expanded to 288 Kbytes 
of RAM through two plug-in expansion 
ports. They can hold either prepro¬ 
grammed ROM cards, or RAM cards (32 
Kbytes or 128 Kbytes). A four-pin RS- 
232 port occupies the front edge, right 
beside the infrared port. The RS-232 
port can connect to a PC compatible or a 
Macintosh with HP’s Serial Interface kit. 
The infrared port can communicate with 
the HP Infrared Printer, an HP28S or 
HP28C, and another HP48SX. The 
screen can display at least three different 
programmable fonts. 

This machine deserves more space 


the Psion Organiser II LZ, the Casio 
BOSS SF-9500, the Atari Portfolio, and 
the Poqet PC (Poqet is pronounced pock¬ 
et). You can probably find many reviews 
that compare every last detail of the new¬ 
est and fanciest PC-compatible laptops. 
I’m not going to do that because each 
“handheld” is very different from the oth¬ 
ers. In fact, they are all targeted at differ¬ 
ent buyers. Almost the only similarity 
they share is that they fit into your hand. 

Of course, these computers do share 
some functions. Three of them have 
spreadsheet capability. All but one allow 
entry of short notes. Nevertheless, I will 
not compare them directly because each 
computer solves problems in its own way. 
The cost of the packages also varies con¬ 
siderably, from less than $600 to more 
than $3,000. 


than is available to describe all its func¬ 
tions, but here is a short list. The 
HP48SX can manipulate and solve alge¬ 
braic equations. It uses 64-bit numbers in 
calculations. It can find derivatives and 
symbolic integrals. It can handle com¬ 
plex numbers and math in hexidecimal, 
decimal, octal, and binary forms. It can 
manipulate vectors and matrices, plot 
(and print) functions, and calculate with 
148 different units. The HP48SX can 
hold real numbers from le-499 to le- 
500. It can do time calculations, statis¬ 
tics, probability, and trig and log func¬ 
tions. All these functions are available 
programmatically. Equations can be en¬ 
tered in textbook form with the Equation 
Writer. 

In the HP tradition, this is an RPN (re¬ 
verse Polish notation) machine. The 
stack is limited only by memory size, 
and operations can be undone several 
ways. You can also use algebraic entry 
for calculations. 

This machine really shines for symbol¬ 
ic math. The Equation Writer allows you 
to enter summations, integrals, algebra, 
and almost any other equation without 


I review each machine in no particular 
order. After you have an idea of each ma¬ 
chine, you can study the various features 
that the machines share (or don’t share) in 
Table A in the sidebar at the end of my 
review. Table A does not directly com¬ 
pare specifications like the pixel size of 
each display or the maximum amount of 
RAM. It shows the machine functions, re¬ 
gardless of how they were implemented. 

A category like secondary storage is im¬ 
plemented in various ways. On some ma¬ 
chines, it consists of battery-backed RAM 
cards. One machine uses a 3.5-inch floppy 
drive for this purpose. 

To wind up the review, I explain the 
appropriate job for each machine and how 
well it fulfills its design goals. 

We’ll see how far the state of the art 
has come since my first Novus 650. 


the intermediate step of converting them 
into algebraic or RPN form. Once en¬ 
tered, equations may be manipulated in 
several ways. Pi and e can be used sym¬ 
bolically or evaluated for a numeric re¬ 
sult. The Solve application allows you 
to solve for a variable in equations of 
any size. When you combine it with the 
plotter, you can find specific roots, 
maxima, minima, intersections, slopes, 
derivatives, and areas. Symbolic algebra 
can express the value of a variable in 
terms of other variables. For example, 
the quadratic x 2 - x - 6 finds the root 
(x - 3)(x + 2). 

Calculations involving units are han¬ 
dled by the calculator, which automati¬ 
cally presents the result in correct units. 
For instance, to express the measurement 
of three feet per second, the calculator 
displays “3_ft/s.” In a matter of two key 
strokes, you can convert that expression 
to miles per hour or fractions of c (the 
speed of light). You can also convert to 
and from any compatible units — cubic 
yards to teaspoons, for instance. 

The HP displays graphs in eight forms, 
including conic sections, function, bar 
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charts, scatter plots, histograms, and 
parametric and truth plots. All print on 
the HP Infrared Printer. 

The programming language is RPL, 
for reverse Polish Lisp. Although I did 
not program the HP to any great extent, I 
did try some public domain programs: a 
Tetris clone, a database, a cash manager, 
a terminal program, a fractal generator, 
and a general-use astronomy program. 
Many of these programs are written by 
veteran HP hackers to add features to the 
HP48SX from older HP calculators. The 
wide range of topics and functions in 
these programs demonstrates the capabil¬ 
ity and power of this machine. I think all 
the applications on the other handhelds 
can be duplicated on the HP48SX. Of 
course, the keyboard is a little rough for 
word processing, but I think a memo edi¬ 
tor like that of the Poqet is possible. 

When you use the SX as a scheduler, 
the time and date display in a corner of 
the screen. They are easily set, and may 
be displayed in 12- or 24-hour format, 
with either slash- or period-delimited 
dates (25.12.90 or 12/25/90). The time 
can be adjusted with soft keys in hours, 
minutes, seconds, or fractions, making it 
easy to synchronize the calculator with 
another time source. The two types of 
alarms are distinguished only by the ac¬ 
tions that occur when they come due. An 
appointment alarm displays a message 
and beeps for 15 seconds. A control 
alarm executes an “object,” typically a 
program. 

You can review the alarms and edit 
them in the Alarm Catalog or set them to 
repeat at any interval from weeks to sec- 


Psion Organiser II LZ 

This lightweight hand-held computer 
is about 8x3x14 cm, or about the size 
of two traditional audio cassettes. It 
comes with a hard plastic removable 
cover that slides on to protect the key¬ 
board while allowing the display to be 
seen. The keyboard is rectangular, with 
36 chiclet keys that include on/clear, 
mode, alphabetic, editing, and shifted nu¬ 
merics. 

The LCD is very high contrast, with 4 
rows by 20 columns. The character set is 
close to that of the IBM PC. Users can 
also program their own characters. Other 
devices may be connected through a 16- 
pin connector located on the top of the 
handheld. 

The Psion is conveniently sized and 
shaped to sit well in one of your hands 
while you type with the other. It is too 


The HP offers many built- 
in functions, but an 
inspired programmer 
can really make 
this machine dance. 


onds. Both types of alarms can be set, re¬ 
called, and edited from a program. Times 
generated can be translated from numeric 
form to strings (for example, 12.251991 
and 9.55 translate to WED 12/25/1991 
9:55:02P). Date and time arithmetic 
functions allow determination of deltas 
and future dates. 

The combination of all these functions 
means that you can easily set the HP to 
run any function at any interval, for any¬ 
thing from data collection to communica¬ 
tion with another computer. Data can be 
downloaded at any future time or upload¬ 
ed at intervals. The HP offers many built- 
in functions, but an inspired programmer 
can really make this machine dance. 

HP calculators are well supported in 
the marketplace. Third-party applications 
have already started to appear for the 
HP48SX, ranging from electrical engi¬ 
neering to surveying. So, even if you 
don’t program it yourself, it is still a ver¬ 
satile machine. 

The only application I reviewed for the 
HP48SX is the HP Solve Equation Li¬ 
brary card. It consists of an equation li¬ 


thick for a trouser pocket but easily fits 
into a jacket or purse. The plastic and 
aluminum case is well built. Psion offers 
a one-year warranty against manufactur¬ 
ing defects. 

The Organiser comes with two manu¬ 
als. The operating manual tells you how 
to configure the machine and gives an in¬ 
troduction and tutorial for each of the 
built-in applications. The programming 
manual is a reference and tutorial for the 
built-in OPL (Organiser Programming 
Language). Both manuals are small, 
well-indexed, coil-bound books. 

The Organiser has an excellent user in¬ 
terface that comes in English, French, or 
German. The main menu runs any in¬ 
stalled application and is user configu¬ 
rable. It is designed to minimize typing 
by letting you cursor around or start ap¬ 


brary, a periodic table, a constants li¬ 
brary, a set of finance functions, a mul¬ 
tiequation solver, and a set of utilities. 
The equation library’s 15 categories in¬ 
clude electricity, forces and energy, and 
solid geometry. Selecting “cylinder” in 
solid geometry provides you with the 
formulas to solve for volume, area, and 
the x- and z-moment of inertia. You can 
even look at a picture of the object to 
identify the variables — it displays a cyl¬ 
inder with all dimensions marked. 

The periodic table lets you walk 
around the table and display relevant in¬ 
formation for all elements, such as the 
symbol, atomic weight, and density. The 
constants library lets you reference 
things like the speed of light, the acceler¬ 
ation of gravity, and Planck’s Constant. 
The finance application provides time- 
value-of-money and amortization. The 
multiequation solver lets you solve prob¬ 
lems involving several equations. The 
utilities are varied, such as a game (ad¬ 
dictive) called Minehunt and a function 
to solve the Fanning friction factor. 

The HP48SX is a well-built, extremely 
well integrated pocket scientific calcula¬ 
tor that probably defines the state of the 
art for calculators. 

The HP 48SX costs $350, the Infrared 
Printer $135, the Solve Equation Library 
$99.95, the PC Serial Interface kit 
$59.95, and the 32-Kbyte RAM card 
$79.95. 

Readers can contact Hewlett-Packard 
Calculator Division at 1030 Northeast 
Circle Blvd., Corvallis, OR 97330. 
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plications by entering the first letter in 
the name. The mode key brings up op¬ 
tions and different functions. This inter¬ 
face consistency makes all the applica¬ 
tions very easy to learn and use. 

The Organiser runs on one 9-volt bat¬ 
tery that should last three months with 
heavy use. The machine warns when 
power is running low (the battery may be 
changed without losing data). Of course, 
if you have it plugged into the wall, this 
is not an issue. The machine shuts down 
after five minutes of inactivity. 

The Psion Organiser II LZ comes with 
32 Kbytes of RAM and 64 Kbytes of 
ROM. There are two slots in the back for 
installing Rampaks (EPROM up to 128 
Kbytes), Datapaks (nonvolatile RAM up 
to 32 Kbytes), or program packs. The 
Rampaks may be reformatted, or data 
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erased. The Datapaks, being EPROM, re¬ 
quire a UV source such as the Psion For¬ 
matter (not reviewed). The packs are 
about the size of a gum eraser. 

The Organiser can connect to several 
input and output devices. The Psion 
Printer II is a ni-cad thermal unit about 
the size of a cloth-bound Tom Clancy 
novel. It prints on 11-cm-wide paper. 

The printer also has an expansion con¬ 
nector for bar code or magnetic stripe 
readers. The bar code reader is a small 
HP model that is easy to carry with the 
Organiser. The mag stripe reader is also 
small but is designed to fasten to surfac¬ 
es. You can also buy the RS-232 Comms 
Link, which allows communications with 
any other device using an RS-232 port. 

Psion applications include a clock, an 
alarm clock, a world clock with a list of 
international cities, a calendar/scheduler, 
a calculator, a diary, a notes editor, and 
the programming language OPL. The ap¬ 
plications are useful and well designed, 
but the real strong point is the OPL inter¬ 
face. Psion has designed OPL to call any 
other Organiser II program and to access 
any data file created by other applica¬ 
tions. Both the bar code and the mag 
stripe readers come with interfaces for 
OPL. When you physically connect the 
bar code reader, OPL receives the BARS 
function. Similarly, the mag stripe reader 
installs the SWIPES function. Program¬ 
ming I/O on these devices is very easy. 

OPL is a Basic-like language with 
functions and structured looping con- 


Casio BOSS SF-9500 

This Executive BOSS (Business Orga¬ 
nizer Scheduling System) is a 255-gram, 
pocket-sized (2 X 17 x 9 cm, closed), 
hand-held computer. It opens along its 
long axis to show a QWERTY chiclet 
keyboard with numerous general and 
special-purpose function keys and an 
LCD. It can open flat or with the screen 
held up at an angle. The function keys on 
the display half are the membrane type, 
while those on the keyboard half are chi¬ 
clet. The home row (A to L) spans only 
about 9 cm (a standard PC keyboard 
spans about 17 cm). It is far too small for 
touch typing. Still, the QWERTY layout 
is a big help, even when you are using 
two fingers to key in a short note. Nei¬ 
ther chiclet nor membrane keys offer any 
sort of tactile feedback, but you can turn 
a beep off or on. 

The 9 x 2.5-cm display can show the 
time in large letters that take up the 
screen or a two-month calendar, seven 
rows by about 40 characters. Normal-use 


This is a great machine 
for applications 
that call for an extremely 
portable computer with an 
RS-232 interface and 
programmability. 


structs that offer easy access to all fea¬ 
tures of the Organiser. Any function is 
callable by any other function. Psion also 
sells a kit that allows a programmer to 
develop applications on a PC compatible, 
compile the code, and download execut¬ 
ables to the Psion. OPL code can be run 
in either interpreted or compiled form. 
The Organiser uses a Harris HD6303X 
microprocessor. 

Psion also included several add-on ap¬ 
plications for review. The 26 x 99-cell 
Pocket Spreadsheet can read and write 
.DIF files exported from programs like 
Lotus 1-2-3 and Quattro Pro. Cells in the 
spreadsheet can call OPL programs, and 
OPL programs can reference spreadsheet 
data and functions. This is another exam¬ 
ple of the fantastic integration of the Or¬ 
ganiser applications and OPL. 


applications such as the memo writer al¬ 
low six rows by 32 characters. Contrast 
and screen-angle adjustments allow you 
to use the machine in almost any lighting 
condition. The BOSS has a huge variety 
of characters in the default font. Al¬ 
though not all are visible on the key¬ 
board, it looks like any accented charac¬ 
ter used by a European language is 
available. 

The BOSS is slightly too large for a 
pants pocket but is easily accommodated 
by a jacket pocket or medium-sized 
purse. Size should never be an impedi¬ 
ment to taking this machine along with 
you. The case is a plastic clamshell with 
a well-designed hinge that allows the de¬ 
vice to be opened flat. Although the out¬ 
side of the case is supposed to be leather¬ 
like, it has a curious — but pleasant — 
wet-suit/dolphin-skin feel. Nothing about 
the construction suggests flimsiness. Ca¬ 
sio offers a one-year warranty against 
manufacturing defects. 


Psion also sells the Maths (sic) Pack. 
This adds functions to OPL for things 
like numerical integration and matrix 
functions. The Finance Pack II applica¬ 
tions range from interest and mortgage 
calculations to a personal account man¬ 
ager. The Spelling Checker, with a set of 
24,000 commonly misspelled words, al¬ 
lows you to look up the spelling of a word 
by just guessing the first few letters. 

The Psion Organiser II LZ is a well- 
built hand-held computer and includes a 
sophisticated programmable I/O inter¬ 
face. Several companies have already 
used these machines for custom applica¬ 
tions such as inventory control and 
equipment diagnosis and adjustment — 
areas where the Psion really shines. This 
is a great machine for applications that 
call for an extremely portable computer 
with an RS-232 interface and program¬ 
mability. 

The Psion Organiser II LZ costs 
$249.95, the bar code reader $249.95, the 
magnetic card reader $199.95, the IBM 
Comms Link (Psion) $99.95, the 32- 
Kbyte Datapak $49.95, the Pocket 
Spreadsheet $79.95, the Finance Pack II 
$49.95, the spelling checker $49.95, and 
the Maths Pack $49.95. Prices of the 
Psion Printer II and Developer Kit (IBM 
PC) were not given. 

Readers can contact Psion Inc. at PO 
Box 790, 118 Echo Lake Rd„ Water- 
town, CT 06795. 
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The BOSS is easy to use but not nec¬ 
essarily intuitive to learn. Casio has de¬ 
signed an interface for a hand-held orga¬ 
nizer — it is not similar to the user 
interfaces of any larger machines. There¬ 
fore, the learning curve is steeper than 
that of handhelds that emulate or run 
MS-DOS. However, a special-purpose 
interface is best in this case. DOS is un¬ 
necessary baggage for an organizer like 
this. 

The BOSS runs on two lithium batter¬ 
ies, rated to last 75 hours with the BOSS 
on. To increase battery life, the machine 
shuts down if it is unused for six min- 

The basic SF-9500 unit has 64 Kbytes 
of storage, of which 56 Kbytes are free for 
user data. Pressing and holding the CAPA 
key provides data on current memory use 
and capacity. A display shows how much 
memory is used, both in bytes and as a 
percentage of the total. Memory may be 
expanded with a 64-Kbyte RAM card that 
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fills the one expansion slot. Data on the 
expansion card is distinct from that in 
main memory and may be copied between 
the two places. This RAM card is pow¬ 
ered by its own lithium battery with a rat¬ 
ed life of one year. 

Casio has included eight useful appli¬ 
cations with the unit: a telephone direc¬ 
tory, a business card directory, a memo 
editor, a schedule keeper with an inte¬ 
grated calendar, two clocks for separate 
time zones, and a calculator. 

The telephone and business card direc¬ 
tories are both databases of entries in a 
structured format. The business card da¬ 
tabase organizes data by employer and 
mailing address, while the telephone da¬ 
tabase typically includes just name, ad¬ 
dress, and phone number. 

The memo editor lets you store up to 
384 characters in each item. Items may 
be searched by scanning the first line of 
each entry. 

The calendar displays any two months 
of the 20th or 21st century in two differ¬ 
ent formats. You can also highlight sig¬ 
nificant dates and holidays. This allows 
you to count working days between any 
two dates. 

The BOSS has two clock displays, for 
“home” time and one other time zone. 
The foreign time zone is selectable from 
a large database of cities. You can also 
set a daily alarm. 

The calculator responds to the num¬ 
bers on the top row of the QWERTY 
keyboard. I have never used a more diffi¬ 
cult layout on a calculator. The Casio 
performs the normal four functions as 
well as square root, percentages, and date 
calculations, and displays them in a 
large, attractive font. However, operation 


Atari Portfolio 

This hand-held MS-DOS 2.11-compat¬ 
ible PC is almost exactly the size of a 
VHS video cassette (2.5 x 10 x 20 cm). 

It weighs a little less than half a kilo. The 
unit hinges open on the long axis to show 
the keyboard on one half and the LCD 
screen on the other. The keyboard has 63 
chiclet keys, including an embedded nu¬ 
meric keyboard, function keys, and an 
Atari (/l\) key for special functions. The 
10.5-cm home row is much too small for 
traditional touch typing. You can manage 
moderate typing speed by holding it with 
two hands and using one or two fingers 
from each hand. This position also offers 
a good view of the screen. 

The screen is 40 columns by 8 lines in 
text mode with a 240 x 64-pixel graphics 


is very clunky. A company like Casio 
knows calculators. Maybe the designers 
think that people who use a BOSS won’t 
need to do many calculations. I hope 
they don’t. 

All Casio BOSS SF models (-7000, 
-7500, -8000, -9000, etc.) can communi¬ 
cate with each other through a supplied 
cable that connects to a serial port on 
each BOSS. You can copy data (like an 
address) one entry at a time, or by cate¬ 
gory. You can also copy everything in 
memory. All data received is stored in 
the form it was sent. If you send an ad¬ 
dress list, it is stored as an address list. 

The BOSS can also communicate with 
a PC clone, using Travelling Software’s 
PC-Link for the Casio BOSS, which re¬ 
sembles one end of Lap-Link. PC-Link 
executes on the PC, giving you a shell to 
view files, and transfers files to and from 
the BOSS over a serial cable. You have 
to type commands on both ends of the 
connection. PC-Link requires you to 
configure the serial port on the BOSS as 
9,600 bps, 7 bits, no parity. I thought 
that 9,600 bps meant fast transfers, but it 
took over 10 minutes to transfer 31 
Kbytes from the PC to the BOSS. This is 
not a big deal — you can send only a 
maximum of 64 Kbytes anyway, and you 
probably would not do that very often. 
PC-Link offers another very important 
capability: You can input data on the PC 
before transferring it to the BOSS. There 
are also translation utilities from PC pro¬ 
grams like Sidekick, Sidekick Plus, PC 
Tools, and programs that write SDF 
(comma delimited) files. 

The BOSS SF-9500 also has a security 
feature that uses a password to protect 
data from prying eyes. 


mode. It is not backlit but has good con¬ 
trast. The characters are large and easy to 
read. You can set the screen at any angle 
from the keyboard up to 180 degrees 
(flat). The contrast is keyboard adjust¬ 
able, and you can use a medium setting 
in any but the darkest situations. The 
40 x 8 screen acts like a window to an 
80 x 25 screen for compatibility with 
desktop DOS programs. 

The case is very solid. The hinge be¬ 
tween screen and keyboard is strong and 
moves with resistance so it stays where 
you leave it. The two halves close to¬ 
gether with two catches and open with a 
sliding switch. The expansion bus, hid¬ 
den behind a cover on the bottom right, 
connects firmly to the serial and parallel 


Along with the BOSS, Casio also pro¬ 
vided me with three applications: Wine 
Companion, Travel Planner, and Electron¬ 
ic Dictionary. The first two databases are 
available as DOS files. Selected parts of 
the databases may be downloaded to the 
BOSS for reference while travelling (or 
dining). Wine Companion might be useful 
to someone who wants to check out a 
wine list electronically. You can use Trav¬ 
el Planner to look up airline phone num¬ 
bers, or restaurants and hotels by category 
or location. 

The Electronic Dictionary ROM card 
contains a dictionary, a thesaurus, a list 
of abbreviations, a guide to usage, and a 
hyphenation table. This is genuinely use¬ 
ful, especially to someone who has trou¬ 
ble with “eye before e.” The application 
can be called up from the Memo Editor 
as well. 

The Casio BOSS SF-9500 is adver¬ 
tised as a personal scheduler and orga¬ 
nizer. It is well designed for that pur¬ 
pose. Don’t expect to use it as a 
calculator or to program it yourself. The 
PC-Link software facilitates data entry 
and storage. The BOSS is small enough 
to carry wherever you go and easy to use. 
If you need the built-in applications, this 
machine is for you. 

The BOSS SF-9500 costs $319.95, the 
PC-Link $119.95, the 64-Kbyte memory 
expansion $129.95, the Electronic Dic¬ 
tionary $129.95, the Wine Companion 
$22.95 (disk based), the Travel Planner 
$22.95 (disk based). 

Casio is located at 570 Mt. Pleasant 
Ave., Dover, NJ 07801. 
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port adapters. The RAM cards slip into 
an expansion slot on the bottom left and 
are held firmly in place. The case itself is 
plastic, with the texture of brushed alu¬ 
minum, and stands up to the abuse of 
travel in a jacket pocket or briefcase. 

The operating system is a DOS-2.11 
look-alike called DIP OS that uses an 
80C88 running at 4.92 MHz. It supports 
common commands and those specific to 
Portfolio functions. The differences con¬ 
sist of commands like Off, App to run 
the built-in apps. Run to run ROM card 
programs, and Help to list the DOS com¬ 
mands. DOS batch files are handled the 
way you would expect, making configu¬ 
ration and simple programming easy for 
someone already familiar with PCs. 
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The Atari should run for many hours 
on three alkaline batteries. The operating 
system has features to conserve power 
while keeping things convenient. The 
screen is refreshed once a second at the 
Fast setting. To save power it can be re¬ 
freshed every 128 seconds or when pro¬ 
grams write to it. The Off command 
switches the Portfolio to standby mode, 
which still uses power with the display 
turned off. The Portfolio automatically 
switches to standby when unused for two 
minutes. When it does switch off like 
that, the state is saved exactly and can be 
restored by touching any key. Any pro¬ 
grams in progress are only suspended, 
not terminated. 

The Portfolio comes with 128 Kbytes of 
RAM that can be shared between DOS 
memory and a RAM disk. The default set¬ 
ting provides about 30 Kbytes for the C di¬ 
rectory; the rest goes to RAM. The Atari 
uses battery-backed RAM cards for sec¬ 
ondary storage. One card at a time can be 
addressed as A: or B:. These cards come in 
several sizes, from 32 to 128 Kbytes. Data 
can be copied between C: and A:. 

The Atari has five built-in applica¬ 
tions: an address book, a calculator, a di¬ 
ary (scheduler), an editor, and a spread¬ 
sheet. The File Manager program lets 
you navigate around the directories and 
start up applications. If you place the 
cursor on a file name with the extension 
.WKS and hit Enter, the spreadsheet pro¬ 
gram opens that file. Data files for other 
built-in programs also work the same 
way. The Atari (/l\) key also starts up a 
menu that lists and starts the built-in pro¬ 
grams. DIP OS has a clipboard that al¬ 
lows cut and paste within files, between 
files, and between applications. All ap¬ 
plications that use text have a search 
function. 


Poqet PC 

This half-kilo PC-compatible hand¬ 
held computer is a little longer than a 
VHS cassette, and about the same depth 
and height (11 X 2.5 x 22 cm). It is 
hinged along the long axis, revealing a 
QWERTY keyboard and a CGA- and 
MDA-compatible LCD screen. The PC 
keyboard is a faithful 3/4-scale repro¬ 
duction. The home row is a little over 13 
cm from A to L. (My PC has a 17-cm 
home row.) It is easy to use, but touch 
typing is a strain. 

The screen has a full 80-character-by- 
25-line display, with adjustable contrast 
and angle. The processor is a 7-MHz 
80c88. While there are a few special 
function keys, the user interface is exact¬ 


The Portfolio is not a PC, 
but it does come close. It is 
well built, easy to use, 
and cheap. 


The Address Book stores hundreds of 
names and tone-dial phone numbers for 
you. Any number of separate databases 
may be maintained in distinct files. Data 
can be entered in the Address Book or 
with the Editor. The file format is simple 
ASCII text, so you can use a PC to enter 
data as long as you have the Parallel Port 
to connect the two machines. 

The simple Calculator has the four ba¬ 
sic functions and percents, exponents and 
roots, and factorials. The display can be 
configured for floating-decimal, fixed- 
decimal, and engineering and scientific 
formats. There are five separate memo¬ 
ries you can use in calculations. The Cal¬ 
culator uses the bottom line of the dis¬ 
play for data entry and keeps the rest of 
the data on a “tape” that scrolls down the 
top of the screen. The best part of the 
tape is that you can edit it to make it 
function as a quick-and-dirty spread¬ 
sheet. When you edit the tape, the results 
change. The tape can be written to a file 
or printed as data is entered. 

The Diary has two modes, Diary and 
Calendar. The Calendar mode shows a 
month at a time and lets you select a day 
to use for appointments. When the day is 
selected, you are placed in Diary mode to 
enter your schedule. Reminders can be 
set to repeat daily (with a weekday selec¬ 


ly the same as an IBM PC or compatible 
running MS-DOS 3.30. The machine 
comes with 512 Kbytes of RAM and 640 
Kbytes of ROM. The ROM contains MS- 
DOS, GW Basic, BIOS, Poqet Tools, and 
Poqet Link. 

The Poqet PC is a well-built piece of 
equipment. The aluminum case closes 
with a very positive click. The RAM and 
ROM cards are loaded in small drawers 
in the bottom the case. It also comes with 
a soft plastic case that has pouches for 
RAM cards. Unfortunately, the case is 
too large for any pocket smaller than 
those in an overcoat, but this handheld 
could easily travel in a briefcase or a 
large purse. 


tion), monthly, or yearly. This is a great 
way to remind yourself to replace the 
RAM card battery at appropriate yearly 
intervals. Alarms can be set for any event 
in your schedule. 

The basic text Editor provides word 
wrap with a configurable right margin. 
Search and replace is easy to use. You 
can also move and delete by character, 
word, and line. Maybe the most useful 
feature (for me) is the undelete function. 
The merge function lets you include oth¬ 
er files in the file being edited. The Edi¬ 
tor can create data files for any applica¬ 
tions that use ASCII files. 

The Spreadsheet is advertised as being 
compatible with Lotus 1-2-3, but that is 
not strictly true. While it can read .WKS 
and .WK1 files, there is a size limit of 
127 columns by 255 rows. You can use 
44 standard functions. The work sheet 
does not handle the database and string 
functions. Even if it lacks the capacity 
and functionality of 1-2-3, the work 
sheet certainly seems enough for meet¬ 
ings, or the road. You can lock titles on 
screen and select two views of the work 
sheet to flip between with a function key. 
Range and format commands are very 
similar to 1-2-3. 

The Portfolio is not a PC, but it does 
come close. It is well built, easy to use, 
and cheap. These factors make it very 
practical to take with you wherever you 
go. 

The Atari Portfolio costs $299.95, the 
serial port $79.95, the parallel port 
$49.95, and the 128-Kbyte RAM card 
$199.95. 

Readers may contact Markem Commu¬ 
nications at 3600 Pruneridge Ave., Santa 
Clara, CA 95051. 
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The Poqet runs on two alkaline AA 
batteries and should last for about 100 
hours. This is achieved by a very sophis¬ 
ticated power-management system. The 
Poqet is never actually turned off — the 
1/0 (on/off) button merely puts the ma¬ 
chine in low-power mode, preserving the 
machine state. Any application running 
is still there the next time you start up. 
This also works when the machine is left 
inactive. 

Poqet Link is a tool similar to Lap- 
Link for moving files between PCs and 
around the disk. It runs at 115,000 bps 
for very fast file copies. 

Poqet Tools includes a calculator, a 
memo editor, a scheduler, an address 
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book, and a terminal emulator. This 
Sidekick-like collection is not so useful 
as one might think. While the calculator 
is handy, the memo editor has an undoc¬ 
umented size limit of 3,999 characters. 
The terminal emulator within Poqet 
Tools proved unreliable. The scheduler 
and address book are much more useful. 
The scheduler maintains a personal 
schedule as well as a task or to-do list, 
and the address book allows searches and 
edits of up to 500 names. 

Fortunately, PC software companies 
have come out in strong support of the 
Poqet and the Poqet format memory 
cards. Several mainstream applications 
are available on ROM cards, including 
Lotus 1-2-3, Lotus Works, Lotus Agen¬ 
da, Word Perfect 5.1, and XYWrite III 
Plus. Poqet provided two applications for 
this review — Lotus Works and Lotus 
Agenda. Agenda is a good match for a 
PC like this because it makes your sched¬ 
ule and organizer software available 
wherever you go. 

Lotus Works (formerly Alpha Works) 
is an integrated software package that in¬ 
cludes a word processor, a database, a 
somewhat Lotus-compatible spreadsheet, 
and a communications program. Each of 
these applications is just what you would 
expect — enough features to do 95 per¬ 
cent of all work, with the added plus that 
all features are available at once. As a 
matter of fact, you can even run multiple 
copies of each application— two spread¬ 
sheets, or three separate word-processing 
applications. 

Although the Poqet is well designed 
and very well built, it is still limited by 
its size. If you purchase this machine, do 
so with small tasks in mind. The key¬ 
board is small and has limited travel. 
Touch typing is difficult, if not impossi¬ 
ble. My fingers fit on the home row only 
when pressed closely against each other. 
The screen is low contrast, and the char¬ 
acters are small. I found Poqet most use¬ 
ful while typing small documents and us¬ 
ing the spreadsheet in Works. 

With those limitations in mind, the 
combination of Lotus Works and the 
built-in Poqet Tools makes this PC a tru¬ 
ly useful tool. While I do not rave about 
the display or the keyboard, there is no 
other way to access this much computing 
power so portably. A tool that is incon¬ 
venient to use (or carry) is the same as 
no tool — it will not be used. This tool 
can and will be used. 

Finally, this machine always seems to 
evoke mixed emotions. It is an amazing 
piece of engineering with unfortunate 
limitations. By claiming (truthfully) IBM 
PC compatibility, the Poqet PC is inevi¬ 
tably compared to —and falls short of — 
larger machines. When compared to oth¬ 
er machines in its “weight” class, it is a 


superior machine. Look at this machine 
as a handheld, and you will see its value. 

The Poqet PC costs $1,395, the floppy 
disk drive $395, the link cable $30, the 
serial modem cable $25, the 512-Kbyte 
RAM card $595, Lotus Agenda $395, 


Conclusions 

All machines reviewed here are re¬ 
markable technical achievements. The 
design goals of several seemed obvious 
to me, while I had to play with the others 
to get a good understanding and appreci¬ 
ation of their engineering. I will not trash 
any of them, but I still acknowledge their 
shortcomings. Shortcomings in comput¬ 
ers that fit in your hand are better 
thought of as “trade-offs” or “design de¬ 
cisions.” None of these machines seem to 
have frivolous limitations. Any trade¬ 
offs are offset by portability. 

The HP48SX is an awesome piece of 


Lotus Works $225, and Poqet Tools for 
DOS $75. 

Poqet Computer Corp. is located at 
650 N. Mary Dr., Sunnyvale, CA 94086. 
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hardware and software. It’s on the lead¬ 
ing edge of calculator science and de¬ 
sign. Using this machine, you could 
probably get a degree in electrical engi¬ 
neering and be safely insulated from any 
tedious calculations or silly mechanical 
mistakes in math or arithmetic. With the 
right frame of mind, you could program 
this machine to do almost anything. 

When considering this machine, think of 
two things. First, you can do most mathe¬ 
matical operations quickly and elegantly 
with the HP48SX. The range of built-in 
functions is impressively complete. If 


Handheld features 

Table A lists some features common to the hand-held computers reviewed here. 
While not all features are built into each computer, a yes entry indicates that the 
feature is available within the packages reviewed. For instance, the Poqet is listed 
as having a word processor. While it ships with a memo editor, the word processor 
I reviewed was within Lotus Works. The Atari is listed as having the capability to 
use a PC for data entry. This is only available with the Smart Parallel Interface. 
The most obvious thing about this table is the number of yeses; there are a lot of 
functional similarities between dissimilar machines. 


Table A. Feature comparisons. 


Software 

HP 

Psion 

Casio 

Atari 

Poqet 

Scheduler 

Yes 

Yes 

Yes 

Yes 

Yes 

Calculator 

Yes 

Yes 

Yes 

Yes 

Yes 

Voice dialer 

No 

No 

No 

Yes 

Yes 

Phone/address list 

No 

No 

Yes 

Yes 

Yes 

Business card list 

No 

No 

Yes 

Yes 

No 

Password protection 

No 

Yes 

Yes 

No 

No 

Terminal emulation 

No 

No 

No 

Yes 

Yes 

Programmability 

Yes 

Yes 

No 

No 

No 

Alarms 

Yes 

Yes 

Yes 

Yes 

Yes 

Spreadsheet 

No 

Yes 

No 

Yes 

Yes 

Database 

No 

No 

No 

No 

Yes 

Word processor 

No 

No 

No 

No 

Yes 

Memo editor 

No 

Yes 

Yes 

Yes 

Yes 

PC data entry 

Yes 

Yes 

Yes 

Yes 

Yes 

Hardware 






Secondary storage 

Yes 

Yes 

Yes 

Yes 

Yes 

Application (ROM) cards 

Yes 

Yes 

Yes 

Yes 

Yes 

Bar code reader 

No 

Yes 

No 

No 

No 

Mag stripe reader 

No 

Yes 

No 

No 

No 

Printer 

Yes 

Yes 

No 

No 

No 

Serial port 

Yes 

Yes 

Yes 

Yes 

Yes 

Parallel port 

No 

Yes 

No 

Yes 

Yes 

PC link 

Yes 

Yes 

Yes 

Yes 

Yes 
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your needs are not covered by the built- 
in functions, there are some other things 
to consider. You could probably program 
the SX to roll over and beg, but that calls 
for a higher level of effort than is really 
necessary here. This is both a plus and a 
minus. Some people will be attracted by 
the flexibility and “hackability” of the 
machine, while others are better off with 
other, simpler tools. Of course, the proto¬ 
typical HP calculator hackers who know 
exactly what they are in for with this ma¬ 
chine will not be disappointed. For $350 
this is a great calculator. The whole 
package with printer can be purchased 
for about $700 — not much for the best 
in class. 

The Psion Organiser II is distinctly 
different from the rest. The basic ma¬ 
chine offers organizer facilities, of 
course. Some of the options expand on 
this with a financial manager, a spread¬ 
sheet, and a spelling checker. The combi¬ 
nation of these tools makes a nice addi¬ 
tion to a traveller’s briefcase. Other 
options include a bar code reader, a mag 
stripe reader, and a portable printer. Add 
this to an integrated programming lan¬ 
guage and development environment, 
and you get an electronic Swiss Army 
knife. So, what is this piece of British 
craftsmanship intended for? Again, there 
are two audiences. A business traveller 
can ignore all the hardware add-ons and 
enjoy access to the smallest spreadsheet 
machine I have ever seen. Anyone can 
use it for small notes, checkbook manage¬ 
ment, and schedules. A reasonable pack¬ 
age for this lists for about $579. An engi¬ 
neer who needs a data-entry machine can 
equip it with a bar code reader and print¬ 
er, add some custom code, and produce a 
very portable inventory machine — a 
front end for any other machine with a se¬ 
rial port. The engineer’s package runs a 
little more, about $900. The Organiser II 
serves several audiences well. 

The BOSS SF-9500 is the top of the 
Casio line of personal organizers. It’s not 
difficult to figure out the BOSS: It’s 
aimed at people who wish to organize 
their lives and are not self-conscious at 
the thought of being on the leading edge 
of personal gadgetry. You do not have to 
be especially technical to use the BOSS 
to the fullest. It offers no chance for pro¬ 
grammability, but an inventive mind 
might certainly use the memo editor as 
an ideal to-do list. For about $700 (list), 
you can build a portable office including 
a PC link, extra memory, an excellent in¬ 
tegrated dictionary, and the BOSS itself 
— a good combination. 

When I first heard rumors about the 
Portfolio several years ago, I knew Atari 
was once again bucking the trend. Five 
years ago, in a world of PC clones. Atari 
produced the 520ST. Two years ago, in a 


world of laptops. Atari produced a 
“palmtop.” For $299 they sold a PC that 
fit in a large pocket. Well, for about 
$630 you can do real work with the Port¬ 
folio. I have taken it on business trips 
and not even noticed it until I needed to 
log in to read e-mail, use a spreadsheet 
for expenses, or write short notes or 
memos. I carried the Portfolio, the serial 


port, and a battery-powered modem. The 
combined weight couldn’t have been 
more than one kilo. 

Think of this machine as a handheld 
rather than a PC compatible. The user in¬ 
terface is the same — CHKDSK, DIR, A:, 
C:, etc. However, you cannot really call a 
machine with 128 Kbytes of RAM and a 
40 x 25 screen a true IBM PC compatible. 


Review notes 

White Knight. This powerful program features a procedural scripting language, 
macros, file-transfer protocols, and multiple terminal emulation. For my purposes, it 
represents one of the best telecommunications packages for the Macintosh. 

White Knight is now packaged in a flashy box with a thick manual. The manual is 
written extremely well and takes you from the basics (like inserting the disk to get 
started) to a set of procedures that lets you get at the guts of the program. 

White Knight started out just after the dawn of the Macintosh with the name Red 
Ryder. Back then it was written in Basic. It has come a long way since. 

The 11.10 version of White Knight that I looked at has added such features as 
color, Zmodem, four variants of Xmodem, three variants of Kermit, Ymodem, and 
support for large-screen monitors. 

If you have a hard disk, setting up White Knight couldn’t be simpler. You begin 
by copying the distribution disk to your hard disk. Then you eject the disk, turn on 
your modem, and start the application. Once you are up and running, you are greet¬ 
ed with a window that includes a general status bar at the top. It divides into five 
clickable sections, each of which tells you something about your current serial port 
settings, elapsed time, and various buttons (for example, pause remote, A P, A S, A C). 

Once you have the modem set up along with the serial port settings, you are in 
modem command mode. You can either enter commands directly or use the phone 
book menu item and let the computer dial it for you. Another option is to go to the 
dial/redial menu item and give it the phone number. Better still, you can write your 
own command procedure or let White Knight write one for you that will dial the 
number, log on, and take you to your destination on that system. The procedural 
language is powerful enough that you can write just about anything you want. You 
can also import and compile your own procedures. 

I had an opportunity to use White Knight on a 1 -Mbyte Macintosh Plus, a 4- 
Mbyte Macintosh Plus, and a 5-Mbyte Mac II with a color monitor. On each ma¬ 
chine I found the software well behaved, easy to use (although I had used Version 

9.4 previously), powerful, and flexible. If you need a telecommunication program 
that can access Compu-Serve as easily as it can your remote network, this is a pro¬ 
gram you will want to consider. 

White Knight requires a 1-Mbyte Macintosh. It retails for $139, which includes 
a free subscription to Genie. Readers can contact the Free Soft Company, 150 
Hickory Dr., Beaver Falls, PA 15010, (412) 846-2700. 

— A lex Polomski 
Reader Service 26 

Norton Utilities 5.0. This version is the newest successor to Peter Norton’s fa¬ 
mous PC software. It completely replaces Version 4.5 and contains 20 new or im¬ 
proved utilities for data recovery, disk repair, disk performance enhancement, and 
data security. Many of the program names have been changed or combined under 
a different name to distinguish them from older versions. Thus the 4.5 programs 
can occupy the same directory to preserve compatibility with user batch files using 

4.5 programs. 

A major improvement in the new version is the enhanced, windowing user inter¬ 
face. For every option available in a window, users receive explanatory text that 
helps them make a correct choice to solve a problem. The new version supports 
different expanded/extended memory schemes offered by IBM and Compaq. It also 
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After all, there is more to compatibility 
than CPU and OS. Capacity and display 
count for a lot. The shared interface, as 
well as the capability to run small DOS 
programs, just makes it easier to use. 

The Poqet PC is quite a machine. It 
costs five times as much as any of the 
rest, but you get a lot for the difference. 
This true compatible is what the Portfo¬ 


lio wants to be — the smallest PC you 
can get. I found no problems running any 
PC programs that I could squeeze onto a 
512-Kbyte RAM card. If you need a PC 
on the road, the Poqet is the smallest way 
to get it. It does not compete with the 
Portfolio because they are not in the 
same class. The Poqet is a PC for the 
power user who likes to travel light. 


provides caching for “normally connected” floppies (floppy drives that do not re¬ 
quire special interfacing). 

The software comes in sets of both 5.25- and 3.5-inch floppies supported by 544 
pages of documentation. Also included in the packet is a quick-refercnce card con¬ 
taining special instructions for emergency unformat and unerase procedures for us¬ 
ers who buy NU 5.0 in the middle of an emergency. The documentation divides 
into two volumes. The User’s Guide covers the following utilities: 

• Norton Disk Doctor II, which repairs most logical and physical disk problems. 

• UnErase to recover deleted files, especially Lotus 1-2-3 and dBase. 

• File Fix and File Save, which repair corrupted files and protect deleted files 
from overwriting for later recovery. 

• Disk Tools to revive defective diskettes, make a disk bootable, and make and 
restore a rescue disk. 

• Speed Disk, which rearranges hard disk files and recommends the most suit¬ 
able way of removing fragmentation. 

• Calibrate for low-level formatting. 

• Ncache for disk caching. 

• Disk Monitor to provide super-write protection against viruses, etc. 

• Diskreet for encrypting/decrypting files and protecting them with individual 
passwords. 

• Wipe Info to completely wipe out files. 

• Safe Format to allow formatting without destroying existing data. 

• Norton Change Directory to provide a graphical interface and flexible com¬ 
mands for selecting, adding, and removing subdirectories. 

• Norton Control Center to allow viewing and changing of hardware settings. 

• System Information to generate extensive reports on hardware, memory usage, 
and benchmarking. 

• Batch Enhancer to help users make their batch files more interactive and attractive. 

Disk Explorer describes a powerful disk editor that allows you to see everything 
that is on a disk and write anything to any location on it. The manual consists of the 
following three sections: 

• Disk Companion introduces and explains basic DOS disk management con¬ 
cepts (such as clusters and a file allocation table). 

• Disk Editor allows users to view different segments on their disks and option¬ 
ally change the contents. 

• Trouble Shooter is a step-by-step guide to using the disk editor to recover from 
serious data-loss problems. 

System requirements are DOS 2.0 or higher, an IBM PC XT, AT, PS/2, or 100 
percent compatible, and 512 Kbytes of RAM. A mouse is supported, and a hard 
disk is recommended. The current version supports large partitions for hard disks 
as found under DOS 4.0 or Compaq DOS 3.31. The software is available from Sy¬ 
mantec Corp., 10201 Torre Avenue, Cupertino, CA 95014. 

— Faisel Saeed 
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NEAREST NEIGHBOR 
PATTERN 
CLASSIFICATION 
TECHNIQUES 
edited by Belur V. Dasarathy 

This book covers the past four decades 
of research in the area of nearest neighbor 
(NN) techniques within the field of pat¬ 
tern recognition, though its emphasis is on 
the more recent studies. It contains results 
and conclusions on nearly 140 studies 
grouped into ten categories, each dealing 
with a specific aspect of development in 
NN pattern classification techniques. 
This tutorial begins with a comprehensive 
survey of the field that includes a detailed 
bibliography of all the studies covered. 
The text contains reprints of 52 studies 
selected from the larger set of studies 
explored in the survey chapter. 

464 pp. 1991. Hardbound. ISBN 0-8186-8930-7. 
Catalog f 1930 $65.00/$45.00Member 
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A thank-you note 

Richard H. Eckhouse, Jr., Product Reviews Editor 


When Bruce Shriver, editor-in-chief 
of IEEE Software, asked me to help 
him with the magazine in 1983,1 was 
extremely flattered —- but I had no 
idea what I would do. At first, I settled 
on the New Products department but 
found it unsatisfying. Reading all the 
new product announcements left me 
with a strong desire to see what was 
so special about them and why read¬ 
ers might find them interesting. As 
luck would have it, after a number of 
issues appeared with my name on the 
department’s masthead, I received an 
actual product to look at. A few more 
trickled in, and I seized the opportuni¬ 
ty to include a few select product re¬ 
views. Bruce then offered me the 
chance to build a separate depart¬ 
ment entirely devoted to new product 
reviews, and I jumped at the chance. 

At first, the problem was finding 
enough material to fill the New Prod¬ 
uct Reviews column. Even though 
IEEE Software appeared only every 
other month, I found it difficult to de¬ 
cide what to review and how to obtain 
the appropriate materials. Many calls 
and letters brought forth about six 
new products to briefly review. People 
were reading my column, and this, in 
turn, resulted in a number of offers 
from those readers who wanted to be¬ 


come product reviewers. With more 
reviewers, it was much easier to cover more 
products, but it was still difficult to obtain 
enough new products to review for our 
fledgling department. Just when every¬ 
thing was beginning to settle down, there 
was change in the air. 

In 1987, Bruce Shriver had been asked 
to become editor-in-chief of Computer, 
and he wanted to know if I would start an¬ 
other new department. Fortunately, I 
could turn things over to Sorel Reisman, 
and — with a promise not to take along 
my cadre of reviewers — I moved on. The 
new department was to start out with only 
a few pages to be filled per month. To 
make this department different from what 
I had done, I set out to develop theme is¬ 
sues rather than individual review articles. 
That turned out to be a bit of a challenge 
because few new reviewers were willing 
to make such a commitment. Over time, I 
again received offers from potential re¬ 
viewers who had read and enjoyed the 
column. Today, the department has met 
most of my goals and is staffed by a loyal 
set of reviewers who appear in several is¬ 
sues each year, and a lot more who make 
a contribution and then move on. 

The reviewers I have worked with at 
IEEE Software and Computer are a spe¬ 
cial breed. You might be interested to 
know that only one person in five who of¬ 


fers to serve actually becomes a re¬ 
viewer. Most don’t last through their 
first review. Only a handful have stuck 
with me more than a year. Why? Be¬ 
cause being a reviewer is a time-de¬ 
manding process that draws on one’s 
expertise to produce the in-depth type 
of review found in this department. For 
this privilege, reviewers may not get to 
keep the product reviewed (whether it 
is software or hardware), must open 
up their personal equipment to install 
software that is sometimes flaky and 
hardware that may not work, and must 
pay to be a member of the Computer 
Society. And, not only that, but they 
have to be able to write! If they wanted 
to (and some have), these reviewers 
could work the professional press cir¬ 
cuit and get paid handsomely for their 
efforts. 

I have been extremely lucky to have 
had the services of these talented re¬ 
viewers, and it is high time I recognize 
them for what they have so unselfishly 
given. I therefore thank all these re¬ 
viewers by acknowledging them in the 
following list. At the same time, I thank 
Bruce Shriver for his constant support 
and the many members of the Com¬ 
puter Society’s professional staff (also 
on the list) who have made this effort 
so worthwhile. 


Product reviewers and professional staff 


Neil Baldridge, Compu-Share 
Valerie Barr, Pratt Institute 
Angela Burgess, IEEE Computer Society 
John Burns 

Rob Carson, IEEE Computer Society 
Noah Davids, Stratus Computer 
Michael Dediu, Dediu Computer Consultants 
Jim Eckhouse, Petro House 

Noah Eckhouse, Massachusetts Institute of Technology 

Quentin Fennessy, University of Massachusetts, Boston 

Mark Fishman, Eckerd College 

Ava Fulton, IEEE Computer Society 

Ed Gallizzi, Eckerd College 

Judith Glaser, Glaser Associates 

Bill Gleason, Martin Marrietta 

Galen Gruman, IEEE Computer Society 

Jan Hackett 

Nancy Hays, IEEE Computer Society 
Chuck Kaman 

Randy Kaplan, Villanova University 

Don Lewine, Profitable Technology 

David Lewis, System Crafts 

Jack Lutts, University of Massachusetts, Boston 

Dan McAuliffe, LPA Software 


Donald Malpass, MIT Lincoln Lab 

Ruth Maulucci, MOCO 

Christine Miller, IEEE Computer Society 

Ron Morash, University of Michigan, Dearborn 

Robert Morris, University of Massachusetts, Boston 

T. L. (Frank) Pappas, AWEB Consulting 

Jan Parmentier, Neuro Kinetics 

Giovanni Perrone, GP Systems 

Alex Polomski 

Marilyn Potes, IEEE Computer Society 

Pete Raeth, United States Air Force 

Sorel Reisman, California State University, Fullerton 

Faisel Saeed, Oklahoma State University 

Mark Sebern, Sebern Engineering 

True Seaborn, IEEE Computer Society 

Bruce Shriver, D.H. Brown 

Dan Simovici, University of Massachusetts, Boston 

Dan Somerville, University of Massachusetts, Boston 

Curtis Swanson, California State College, Fullerton 

Richard Tenney, University of Massachusetts, Boston 

Terry Traub, Fidelity Financial Services 

Allan Wasserman, Oregon State 

Gerry Weisman, Rehabilitation Technology Services 

Steve H. Wilcox, IEEE Computer Society 
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Guarding Pacific Rim intellectual property rights is focus of conference 

Robert J. Melford, R.J. Melford Associates 


The continuing development of laws 
and enforcement practices to protect such 
intellectual property as computer soft¬ 
ware in the US and many Pacific Rim 
countries was the focal point of the 1991 
Pacific Rim Computer Law Conference. 
Sponsored by the Washington, DC-based 
Computer Law Association, the confer¬ 
ence was held February 14-15 in New¬ 
port Beach, California. 

More than 100 predominantly legal 
practitioners from throughout the Pacific 
Rim met to address the status of legal 
practices in the computing industry. The 
keynote speaker was Safi U. Qureshey, 
president and CEO of AST Research, Ir¬ 
vine, California. His remarks under¬ 
scored the continuing trend toward an 
underlying standard of basic patent, 
trademark, and copyright protections en¬ 
forced by Pacific Rim nations such as the 
US, Japan, Hong Kong, the People’s Re¬ 
public of China, Taiwan, Korea, and 
Australia. 

In a series of eight panel discussions, 
speakers tracked the continuing develop¬ 
ment and understanding of software pro¬ 
tection practices in those countries. 

Many panelists talked about the increas¬ 
ing commonality of copyright protection 
measures that these nations apply to soft¬ 
ware. Specifically, the national laws dis¬ 
cussed at the conference share a collec¬ 
tive heritage with Anglo and American 
common law traditions. 

Strategy panel. In a discussion titled 
“Software Pirates and Hardware Coun¬ 
terfeiters: Combat Strategies in the Pacif¬ 
ic Rim,” Eric H. Smith, a Washington, 
DC, attorney, reviewed US efforts begun 
in the early 1980s to encourage many Pa¬ 
cific Rim nations to adopt more effective 
intellectual property-right protection 
laws. He supported the convictions of 
other conference speakers who said the 
threat of economic trade sanctions is re¬ 
sponsible for the relatively rapid adop¬ 
tion pace. 

Fellow panelist Paul Scholefield, Dea¬ 
cons Law Firm, Hong Kong, supported 
this position, adding that domestic con¬ 
cerns about being labeled “a haven for 
[software] pirates and [hardware] coun¬ 


terfeiters” by other countries also have 
played a significant role in the adoption 
and increased enforcement of these intel¬ 
lectual property-rights protection mea¬ 
sures. He pointed to Singapore as an ex¬ 
ample. 

Scholefield said the current growth 
states for pirating activities are Vietnam 
and the PRC, where the establishment of 
protective laws and their accompanying 
enforcement mechanisms only recently 
began. 

The speakers and other conference 
participants generally agreed that an in¬ 
ternationally accepted general standard 
of intellectual property protection laws 
and enforcement mechanisms would en¬ 
courage a more efficient environment for 
developing, producing, and marketing 
computer hardware and software. 

Qureshey indirectly supported that 
perspective in his talk. He said standards 
have played a pivotal role in the personal 
computer marketplace’s rapid develop¬ 
ment and sustained growth. He was care¬ 
ful to clarify his position that standards 
are most suitable in applications where 
the function they describe is unlikely to 
change as rapidly as the technology used 
to implement it (for example, communi¬ 
cations protocols tend to change less rap¬ 
idly than the design of the hardware sup¬ 
porting their implementation). 

Standards enable manufacturers to 
concentrate on improving the price- 
performance ratio for a given function, 
Qureshey noted. Therefore, consumers 
benefit from a market economy that al¬ 
lows for competitive product compari¬ 
son. Qureshey ridiculed IBM’s attempt 
to reverse the industry’s encouragement 
of interoperable standards through intro¬ 
duction of the proprietary Micro Channel 
that has “relegated [IBM] to the less- 
than-20-percent market share category” 
in the PC market. 

Qureshey chided “Boston-based manu¬ 
facturers” such as Digital, Wang, and 
Prime because “they are now paying the 
cost of not adopting standards.” He also 
sought to temper concerns about the on¬ 
going debate between competing propos¬ 
als for a Unix standard by saying, “Two 
Unix standards are better than many.” 


Qureshey closed by saying he envi¬ 
sioned standards as a “means of leveling 
the playing fields of competition world¬ 
wide” by eliminating opportunities for 
nationalistic finger-pointing. 

Concerns for the future. After the 
conference, Stephen H. La Count, the 
conference chair — who is with Stra- 
dling, Yocca, Carlson, and Rauth, New¬ 
port Beach, California — said there are 
two new areas of concern in the comput¬ 
ing science and the computer law and 
software-marketing communities. One, 
he said, is related to the recent Lotus De¬ 
velopment-Paperback Software “look 
and feel” decision and revolves around 
copyright law interpretation. The other 
concerns policy decisions regarding as¬ 
sessing and/or collecting royalty or li¬ 
censing fees for network-environment 
software. 

Regarding the Lotus case, G. Gervaise 
Davis III — of Schroreder, Davis, and 
Orliss, Monterey, California — identi¬ 
fied a key factor that influenced the 
court’s decision favoring Lotus and that 
might evoke considerable computer sci¬ 
ence and software development commu¬ 
nity concern. 

For clarification, “a copyright protects 
only the right to copy the expression of 
an idea, not the use of the idea itself.” 1 In 
fact. Justice Sandra Day O’Connor wrote 
in a unanimous US Supreme Court deci¬ 
sion that “all ideas in general circulation 
be dedicated to the common good unless 
they are protected by a valid patent.” 2 In 
cases where expression of ideas is not 
protected by patent, the Supreme Court 
has also held that any “fair and honest 
means, such as by independent invention, 
accidental disclosure, or so-called re¬ 
verse engineering, that is by starting with 
a known product and working backwards 
to divine the process that aided in its de¬ 
velopment or manufacture,” 3 is a legiti¬ 
mate practice to better understand the 
idea and its application. 

Legal-economic battle. In his paper 
“Reverse Engineering and the Computer 
Industry: A Battle Between Legal and 
Economic Principles,” Davis argued that 
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the court regarded Paperback’s necessity 
to reverse-engineer the Lotus 1-2-3 
spreadsheet to duplicate its function 
without copying its coding as a bad-faith 
(dishonest) act, therefore showing in¬ 
fringement on the Lotus copyright, prima 
facie. 

A number of courts have adopted this 
view, Davis said. Through the conse¬ 
quent prevention of the use or applica¬ 
tion of the idea the reverse engineer 
sought to understand, the courts have vir¬ 
tually provided the copyright holder with 
the equivalent of a 75-year patent (actual 
patents last 17 years), thus “taking these 
ideas and information from the public 
domain, without the orderly and very re¬ 
strictive process of patent examination,” 
he said. 

Davis also explained that, spurred by 
IBM, DEC, and a number of other com¬ 
puting industry firms, this misdirected 
view regarding reverse engineering has 
now extended to US Trade Representa¬ 
tive efforts to encourage other nations to 
strengthen their intellectual property pro¬ 
tection statutes. 

If software and other expressions of 
ideas created and marketed by other 
countries threaten the current dominance 
of domestic products (such as Japanese 
cars), “executives and engineers in the 
US computer industry may well be dev¬ 


astated and severely restricted by over¬ 
protection of software in years to come,” 
Davis warned. 

Licensing perspective. In the software 
licensing matter, the issue pertains to 
how a software vendor receives a return 
for a product used on a network. R. Duff 
Thompson, vice president and general 
counsel, Word Perfect, Orem, Utah, put 
the matter in perspective. He explained 
that only 2 percent of Word Perfect’s 
programs were used on networks in 
1982, but the figure rose to 35 percent 
last year and was expected to reach 70 
percent by 1995. 

Thus, software vendors have found it 
difficult to justify licensing on the exclu¬ 
sive basis of how many individual hard¬ 
ware platforms execute the software. 

This has led to marketplace confusion. 
Some vendors choose to license based on 
the number of computers attached to the 
network and others on the number of us¬ 
ers permitted to log on to the network. 
Some vendors only consider how many 
users are allowed to use the program, 
while others are concerned with how 
many users are permitted to use their 
software simultaneously, and still others 
may employ other standards. 

But, as Thompson indicated, “Word 
Perfect recognizes [that] reasonable 


minds can differ on any solution.” This is 
an issue technology may help to resolve, 
but only the marketplace will drive the 
final solution. 


To go further 

For more information on intellectual 
property protection, contact Richard H. 
Stern, Chair, Subcommitee on Intellectu¬ 
al Property Protection, IEEE Computer 
Society Committee on Public Policy, 
Suite 400, 1300 19th St. NW, Washing¬ 
ton, DC 20036, phone (202) 659-1385. 
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CALL FOR PAPERB 

APPLYING QUALITY TECHNOLOGIES to 
Sfj CREATE WORLD CLASS SOFTWARE SYSTEMS 

D»yton Convention Confer, Dayton, Ohio October 0-0, 1 eel 

The need to make effective use of existing technologies and tools for improving the quality of software and the processes used to 
create that software is becoming more prevalent today than 5 short years ago. Organizations from all nations are recognizing the 
critical importance of quality in successfully developing complex software products and systems. 

This call for papers seeks open and informed discussion among system and software engineers, managers, software quality 
practitioners, and others interested in the application of software quality technology, and the continuous improvement of product 
quality. This conference is intended to be the premiere international forum for exploring the science and practice of 
applying quality technologies to software engineering disciplines. 

Several tracks, consisting of both formal technical presentations, and informal thematic panel discussions are planned. 

Topics of interest include, but are not limited to the following: 



Prospective authors should submit four (4 ) copies of a 300 word abstract and a brief biographical sketch of each author to the 
Program Committee by April 30,1991. Papers must be cleared for publication and have not been previously published. 

Those interested in submitting panel proposals or tutorial proposals should contact the ICSQ Conference Chairperson. 

TOOLS FAIR: A software tools fair will be held during the conference. Those who would like to exhibit or demonstrate 
a tool should contact: Charles Bering, Litton Computer Services, 4020 Executive Drive, Dayton, Ohio 45430 (513) 429 - 6344 
CALL FOR EXHIBITS: For information, contact Phil Marriott. ICSQ Chairperson. 

IMPORTANT DATES: Submission deadline for abstracts: April 30, 1991; Acceptance notification and author kits forwarded by: 

May 31,1991; Final versions due July 15, 1991. 



Sponsored by: American Society for Quality Control Software Division American Society tor Quality Control Dayton Section 
























COMPASS '91 

6th Annual Conference on Computer Assurance 

National Institute for Standards and Technology, Gaithersburg, MD June 24-28,1991 

An International Conference Sponsored by IEEE National Capital Area Council & 
IEEE Aerospace and Electronic Systems Society 


ADVANCE REGISTRATION 

[ ] CONFERENCE REGISTRATION 

[ ] PROCEEDINGS ONLY 

[ ] TUTORIAL (Linking Fault Trees and Petri Nets) 

[ ] TUTORIAL (Safe Systems) 


FEATURED SPEAKERS 

John Cullyer, University of Warwick 
David L. Pamas, Queens University 
H. O. Lubbes, Naval Research Laboratory 

PANELISTS 

David L. Pamas, Queens University 

John Chemiavsky, National Science Foundation 

David L. Pamas, Queens University 

Peter J. Denning, NASA Ames Research Center 

William L. Sherlis, DARPA 

John A. McDermid, University of York/British Computer Society 

Brace Barnes, National Science Foundation 

Raymond Miller, University of Maryland 

Diane Jachinowski, Nellcor 

Peter G. Neumann, SRI International 

J. Alan Taylor, British Computer Society 

Claire Lohr, Lohr Systems 

William Junk, University of Idaho 

TUTORIALS 

Safe Systems—A Disciplined Approach 
John McDermid, University of York 
John Cullyer, University of Warwick 
Software Safety Analysis—Linking Fault Trees and Petri Nets 
Janet Gill, Patuxent River Naval Air Test Center 

SESSIONS 

Industry Training on Computer Assurance 
European Economic Community '92 Perspectives 
Certification and Safety of Critical Systems 
US and International Sponsored Initiatives 
Risk Containment Planning and Quality Measurements 
Formal Methods 

COMPUTER RELATED RISK OF THE YEAR 

Weak Links and Correlated Events 

Peter G. Neumann, SRI International 

FEES 

Lunches and banquet not included in student fee. Advance registration 
ends 8 June 1991. Requests for refunds after 8 June 1991 will be 
subject to a $15 administrative fee. For further details, contact Dolores 
Wallace, (301) 975-3340. 

Note : Due to new security procedures at NIST, you must register in 
advance, or contact Andrew Moore prior to 20 June 1991. Phone 
(202)767-6698; or email moore@itd.nrl.navy.mil. 


[ ] EXTRA PROCEEDINGS (number:_) 

NAME _ 

COMPANY _ 

ADDRESS _ 

CITY _ STATE_ZIP_ 

COUNTRY_PHONE_ 

IEEE membership number (or co-sponsor name)_ 

Check method of payment: 

[ ] check Amount enclosed $_made payable to COMPASS 

'91. 

[ ] American Express [ ] Visa 

[ ] Mastercard [ ] Diners Club 

AccL #_Exp. date_ 

Signature- 

Mail to: COMPASS ’91, 1100 S. Barton St. #289, Arlington, VA 22204 
USA; or fax to Dolores Wallace, NIST, (301)590-0932. 


HOTEL REGISTRATION 

Please make reservations directly with the hotel and refer to COMPASS 
’91. Complete all information and check desired accomodation. 
COMPASS ’91 room rate (single or double, not including tax) is $55.00. 
Reservations must be made by 7 June 1991 to take advantage of this 
rate. One nights deposit is required when making reservations. 

NAME _ 

COMPANY _ 

ADDRESS _ 

CITY_STATE_ ZIP_ 

COUNTRY_ PHONE_ 

Please guarantee for late arrival: $_ [ ] Single [ ] Double 

[ ]check 

[ ] American Express [ ] Visa [ ] Mastercard 

Acct. #_ Exp. date_ 


Mail to: Holiday Inn, Two Montgomery Village Avenue, Gaithersburg, 
MD 20879; or phone (301)948-8900. 



Advance (ends 6/8) 

On-Site 

Students 

M 

NM 

M 

NM 

M 

NM 

Conference 

225 

275 

275 

325 

25 

75 

Tutorial 

50 

70 

70 

90 

25 

45 

Proceedings Only 

20 

20 | 

1 20 

20 

20 

20 


M = Member of IEEE or a Sponsoring Organization; NM = Not a member of any Sponsoring Organization. 













































IEEE COMPUTER SOCIETY PRESS VIDEOTAPES 


ARTIFICIAL NEURAL SYSTEMS 

by Bruce Shriver 


ISO-ANSI SQL STANDARDS 

by Phil Shaw 


Introduces the viewer to artificial neural systems, presents 
terminology, provides a review of work in the field, and discusses 
current applications. 

150 min. Videotape # 1988AV. Video Notes Booklet # 1988N. 60 pp. 


CASE TECHNOLOGY 

by Elliot J. Chikofsky 


Surveys CASE technology, from its origin in software tools and 
methodology development through the implementation of large- 
scale, integrated environments. 

180 min. Videotape # 2098AV. Video Notes Booklet it 2098N. 44 pp. 

COMMUNICATION AND SYNCHRONIZATION IN 
PARALLEL PROCESSING SYSTEMS 
by Harold S. Stone 

Addresses the problems of synchronization of multiple processors 
and discusses general approaches to overcoming potential 
bottlenecks in highly parallel systems. 

150 min. Videotape # 1991AV. Video Notes Booklet # 1991N. 98 pp. 

DESKTOP PUBLISHING FOR TECHNICAL WRITERS 

by Richard Ziegfeld 


This tape outlines the status of various stages of SQL standards 
and describes all of the SQL2 features. 

150 min. Videotape # 1992AV. Video Notes Booklet it 1992N. 150 pp. 

OBJECT-ORIENTED PARADIGM 

by Dipayan Gangopadhyay 

Covers the basic concepts and definitions, examines the impact of 
software design methodology, and discusses technical issues and 
the future directions of object-oriented design and programming. 
180 min. Videotape it 2096AV. Video Notes Booklet it 2096N. 54 pp. 

OSI AND TCP/IP: IMPACT ON SOFTWARE 
VENDORS AND USERS 

by William Stallings 

Examines the issues relating to the transition from TCP/IP to OSI, 
beginning with a brief summary of the two architectures and a 
discussion of the need for a transition strategy. 

180 min. Videotape it 2093AV. Video Notes Booklet # 2093N. 58 pp. 

PARALLEL PROCESSING: ARCHITECTURE & DIRECTIONS 

by William J. Dally 


Defines a new process that allows authors to write and produce an 
effective software-based product and discusses its opportunities 
and limitations. 

180 min. Videotape it 840AV. Video Notes Booklet it 840N. 136 pp. 

DISTRIBUTED-SOFTWARE ENGINEERING 

by Sol M. Shatz 

Covers major topics such as distributed computing and software 
engineering, distributed-software partitioning and allocation, dis¬ 
tributed programming, and distributed-software testing. 

150 min. Videotape it 856AV. Video Notes Booklet it 856N. 47 pp. 

DISTRIBUTED SUPERCOMPUTING 

by Jordan Becker 

Ties together topical supercomputing subjects including high- 
performance computing, visualization and graphics, and remote 
access networking. 

150 min. Videotape# 1993AV. Video Notes Booklet # 1993N. 61 pp. 

ENGINEERING SOFTWARE SYSTEM DEVELOPMENT, 
ACQUISITION, AND USE WITH SOFTWARE RELIABILITY 
MEASUREMENT 
by John Musa 

The tape presents some basic concepts and discusses applications 
to show how software reliability measurement can guide engineers 
and managers in achieving a desired level of software quality. 

150 min. Videotape # 1994AV. Video Notes Booklet # 1994N. 57pp. 

IMPROVING THE SOFTWARE PROCESS AND 
PRODUCT IN A MEASURABLE WAY 

by Victor Basili 

Presents the fundamental ideas behind software process and 
product improvement using measurement, discusses how the 
approach is being used, and includes various models and metrics. 

150 min. Videotape # 1990AV. Video Notes Booklet # 1990N. 63 pp. 

ISDN: A STATUS REPORT 

by William Stallings 

Includes an overview of ISDN, its history, architecture, and 
services. Plus, the 1990 specifications of B-ISDN and the services, 
and the use of the asynchronous transfer mode are discussed. 

180 min. Videotape # 823AV. Video Notes Booklet # B23N. 62 pp. 


Gives an overview of parallel processing, describes some current 
directions in the field, and presents programming examples of 
shared memory, message-passing, and data-parallel machines. 

150 min. Videotape # 1989AV. Video Notes Booklet # 1989N. 80 pp. 

THE SOFTWARE FACTORY 

by Victor Basili 

Offers built-in mechanisms and evolutionary learning techniques 
on how to better develop software using previous software experi¬ 
ence in the form of knowledge, processes, and products. 

180 min. Videotape # 2094AV. Video Notes Booklet # 2094N. 78 pp. 

SOFTWARE RISK MANAGEMENT 

by Barry Boehm 

The aim of this presentation is to establish a software risk 
management discipline to help software projects avoid disaster 
through risk assessment and risk control. 

150 min. Videotape # 1906AV. Video Notes Booklet # 1906N. 21 pp. 

TOPICS IN REUSE AND DESIGN RECOVERY 

by Ted Biggerstaff 

This tape examines successful reuse, and analyizes cases and their 
key characteristics. It also explores the representational 
requirements for human understanding of various programs. 

180 min. Videotape # 2099AV. Video Notes Booklet # 2099N. 100 pp. 

VISUALIZATION IN SCIENTIFIC COMPUTING 

edited by Bruce Shriver and Gregory Nielson 

A companion to the Visualization in Scientific Computing book, it 
fully illustrates this subject, includes programmed animation, and 
most of the authors from the tutorial present their research. 

120 min. Videotape # 1979AV. ["$59.00 Member Price $49.00] 

ALL VIDEOS INCLUDE ONE SET OF VIDEO NOTES, 
ADDITIONAL SETS CAN BE PURCHASED SEPARATELY 

ALL VIDEOTAPES, EXCEPT WHERE NOTED, 

LIST FOR $129.00, MEMBER PRICES ARE $99.00 


To order these Video Sets call: 

1-8QO-CS-BOOKS or 714-821 -8380 













CALENDAR 


In the accompanying Calendar and adjoining Call for Papers, the IEEE 
Computer Society logo identifies the conferences the society is participat¬ 
ing in or sponsoring. Other conferences of interest to our readers, as well as their 
sponsors, are also listed. 

For inclusion in Call for Papers or Calendar, submit the following information: 
event name, date(s), location, and sponsor(s) as well as the phone and fax num¬ 
bers and the electronic address of the person to contact. In addition, for Call for 
Papers listings, include the name of the person to whom papers should be sub¬ 
mitted and the deadline for submittals. 

The above-mentioned information should arrive at Computer at least five 
weeks before the month of publication (i.e., for the June 1991 issue, send in¬ 
formation for receipt by April 22, 1991) to Chuck Governale, Calendar Dept., 
Computer, PO Box 3014, Los Alamitos, CA 90720-1264, fax (714) 821-4010, 
e-mail c.governale@compmail.com. 


April 1991 


PPOPP 91. Third Symp. on Principles and 
Practice of Parallel Programming, Apr. 21- 

24, Williamsburg, Va., Sponsor: ACM 
SIGPlan. Contact Dennis Gannon, Computer 
Science Dept., Indiana Univ., 101 Lindley 
Hall, Bloomington, IN 47401. 


® CHDL 91,10th Int’l Symp. on Com¬ 
puter Hardware Description Lan¬ 
guages and their Applications, Apr. 22-24, 

Marseille, France. Cosponsors: Int’l Federa¬ 
tion for Information Processing et al. Contact 
Dominique Borrione, Imag/Artemis, BP 53X, 
38041 Grenoble Cedex, France, phone (33) 
7651-4604, ext. 5240, fax (33) 7651-9637, 
e-mail borrione@imag.imag.fr. 


Second Int’l Conf. on Systems Inte- 
yg? gration, Apr. 22-25, Morristown, N.J. 
Cosponsors: New Jersey Inst, of Tech, et al. 
Contact Peter A. Ng, Computer and Informa¬ 
tion Science Dept., New Jersey Inst, of Tech., 
University Heights, Newark, NJ 07102, phone 
(201) 596-3387, fax (201) 596-5777, e-mail 
ng_p @ vienna.njit.edu. 

NCGA 91,1991 Nat’l Computer Graphics 
Assoc. Conf., Apr. 22-25, Chicago. Contact 
NCGA, 2722 Merrilee Dr., Suite 200, Fairfax, 
VA 22031, phone (800) 225-NCGA or (703) 
698-9600, fax (703) 204-4521. 

ijrljS Transputing 1991, Apr. 22-26, Sunny- 
vAy vale, Calif. Sponsor: Inmos Corp. Con¬ 
tact G.S. Stiles, Electrical Eng. Dept., Utah 
State Univ., Logan, UT 84322-4120, phone 
(801) 750-2806, fax (801) 750-3054. 


Second European Distributed Memory 
Computing Conf., Apr. 22-24, Munich, Ger¬ 
many. Cosponsors: Gesellschaft fur Informa- 
tik et al. Contact Arndt Bode, Computer Sci¬ 
ence, Technische Univ. Munich, POB 20-24- 
20, D-8000 Munich 2, Germany, phone 49 
(89) 2105-8240, e-mail bode@infovax. 
informatik.tu-muenchen.dbp.de. 

KMET 91, Int’l Conf. on Knowledge Mod¬ 
eling and Expertise Transfer, Apr. 22-24, 

Sophia Antipolis, France. Cosponsors: Assoc. 
Francaise pour la Cybernetique Economique 
et Technique et al. Contact KMET 91, Univ. 
de Nice, Sophia Antipolis, CNRS, 13S- 
LISAN, Daniele Herin-Aime, bat. 4, rue A. 
Einstein, 06560, Valbonne, France, phone 
(33) 92-94-26-27, fax (33) 92-94-28-98, 
e-mail dh@cerisi.cerisi.fr. 


CHI 91,1991 Conf. on Human Fac¬ 
tors in Computing Systems, Apr. 27- 

May 2, New Orleans. Sponsor: ACM. Contact 
Toni MacHaffie, 18988 SW Shaw, Aloha, OR 
97007, phone (503) 592-1981, fax (503) 591- 
0120, e-mail machaffie.chi@xerox.com; Keith 
Butler, Boeing, Advanced Tech. Center, PO 
Box 24346, MS 7L-64, Seattle, WA 98124, 
phone (206) 865-3389; or June Davis, 13 An¬ 
napolis St., Annapolis, MD 21401, phone 
(301) 269-6801. 

Distributed Memory Computing Conf., 

Apr. 28-May 1, Portland, Ore. Cosponsors: 
Oregon Advanced Computing Inst., Univ.of 
Michigan. Contact Walter G. Rudd, OACI, 
19500 NW Gibbs Dr., Suite 110, Beaverton, 
OR 97006-6907, phone (503) 690-1051, fax 
(503) 690-1210, e-mail rudd@oacis.org. 


Second Eurographics Workshop on Visual¬ 
ization in Scientific Computing, Apr. 22-24, 

Delft, the Netherlands. Cosponsors: Delft 
Univ. of Tech, et al. Contact Andrea J.S. Hin, 
Eurographics VISC Workshop, TU Delft, Fac¬ 
ulty of Tech. Math, and Informatics, PO Box 
356, 2600 AJ Delft, the Netherlands, phone 31 
(15) 783-630, fax 31 (15) 786-522, e-mail 
andrea@duticg.tudelft.nl. 


IEEE Posix Open Systems Seminar, 
Apr. 29-30, San Diego, Calif. Contact 
IEEE Standards Seminars, 445 Hoes Lane, PO 
Box 1331, Piscataway, NJ 08855-1331, phone 
(908) 562-3805. 

ECF 91, Eastern Comm. Forum, Apr. 29- 

May 1, Washington, DC. Sponsor: Nat’l Eng. 
Consortium. Contact NEC, 303 E. Wacker 


Dr., Suite 740, Chicago, IL 60601, phone 
(312) 938-3500, fax (312) 938-8787. 


Int’l Conf. on Cognitive Sciences, 
N&7 Apr. 29-May 2, Montreal. Cosponsors: 
AFCET et al. Contact Gilles Gauthier, Math, 
and Computer Science Dept., Univ. of Que¬ 
bec, PO Box 8888, Station A, Montreal, Que., 
Canada H3C 3P8, phone (514) 987-8212, fax 
(514) 987-8477. 


Fifth Int’l Parallel Processing Symp., 
v|y Apr. 30-May 2, Anaheim, Calif. Spon¬ 
sor: IEEE Computer Soc. Orange County 
Chapter. Contact Larry H. Canter, Computer 
Systems Approach, 1140 S. Raymond Ave., 
Suite B, Fullerton, CA 92631, phone (714) 
738-3414, fax (714) 738-3470. 


Instrument Soc. of Am. Fdmonton 91 
Conf., Apr. 29-May 3, Edmonton, Alta., Can¬ 
ada. Contact Ian Verhappen, PO Box 41035, 
200 Petrolia Post Office, Edmonton, Alta., 
Canada T6J 6M7, phone (403) 790-7917, fax 
(403) 790-7930. 


May 1991 

22nd Pittsburgh Conf. on Modeling and 
Simulation, May 2-3, Pittsburgh. Sponsor: 
Univ. of Pittsburgh. Contact William G. Vogt 
or Marlin H. Mickle, Modeling and Simula¬ 
tion Conf., 348 Benedum Eng. Hall, Univ. of 
Pittsburgh, Pittsburgh, PA 15261. 

SID 91, 1991 Int’l Symp., Seminar, and Ex¬ 
hibition, May 6-10, Anaheim, Calif. Sponsor: 
Soc. for Information Display. Contact SID, 
c/o Palisades Inst, for Research Services, 201 
Varick St., Suite 1140, New York, NY 10014, 
phone (212) 620-3371, fax (212) 620-3379. 

IEEE Pacific Rim Conf. on Comm., Com¬ 
puters, and Signal Processing, May 9-10, 

Victoria, B.C., Canada. Cosponsors: IEEE 
Victoria Section, Univ. of Victoria. Contact 
Technical Program Committee, c/o Pan Ag- 
athoklis, Electrical and Computer Eng. Dept., 
Univ. of Victoria, PO Box 3055, Victoria, 
B.C., Canada V8W 3P6, phone (604) 721- 
8618, fax (604) 721-8676. 

Second Int’l Workshop on Human and Ma¬ 
chine Cognition, May 9-11, Pensacola, Fla. 
Contact Ken Ford, Inst, for Human and Ma¬ 
chine Cognition, Div. of Computer Science, 
Univ. of West Florida, Pensacola, FL 32514, 
phone (904) 474-2551, e-mail kford@uwf. 
bitnet. 


/Q-jj) CBMS 91, Fourth IEEE Symp. on 
VS7 Computer-Based Medical Systems, 
May 12-14, Baltimore. Cosponsors: IEEE 
Computer Soc., IEEE Eng. in Medicine and 
Biology Soc., and IEEE Baltimore Section. 
Contact Jeffery C. Lesho, Johns Hopkins 
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Univ., Applied Physics Lab., Bldg. 13-S112, 
Johns Hopkins Rd., Laurel, MD 20723-6099, 
phone (301) 953-5000, ext. 8057, e-mail 
lesho@aplcomm.jhuapl.edu. 

CICC 91, IEEE Custom Integrated Circuits 
Conf., May 12-15, San Diego, Calif. Contact 
Jim Lipman, VLSI Tech., 1109 McKay Dr. 
MS-32, San Jose, CA 95131, phone (408) 
434-7673. 

® IEEE SCC 20 Meeting on Expert Sys¬ 
tem Standards for Test and Automat¬ 
ic Test Equipment, May 12-17, Prien, Ger¬ 
many. Contact R. Glenn Wright, GMA Indus¬ 
tries, 85 First Ave., Atlantic Highlands, NJ 
07716, phone (908) 291-7600; or Helmut 
Scheibenzuber, MBB, Postfach 801160, 8000 
Munich 80, Germany. 

44th Conf. of the Soc. for Imaging Science 
and Tech., May 12-17, St. Paul, Minn. Con¬ 
tact SPSE, 7003 Kilworth Lane, Springfield, 
VA 22151, phone (703) 642-9090, fax (703) 
642-9094. 

Second Eurographics Workshop on Ren¬ 
dering, May 13-15, Barcelona, Spain. Co¬ 
sponsors: Univ. Politecnica de Catalunya. 
Contact Xavier Pueyo, Dept. Llenguatges i 
Sistemes Informatics, Univ. Politecnica de 
Catalunya, Av. Diagonal, 647 planta 8, 08028- 
Barcelona, Spain, phone 34 (3) 401-6667, fax 
34 (3) 401-6600, e-mail eapueyo@ebrupc51. 
bitnet or xavier@lsi.upc.es. 

® ICSE 13, 13th Int’l Conf. on Software 
Eng., May 13-17, Austin, Texas. Co¬ 
sponsor: ACM. Contact Barbara Smith, MCC 
Software Tech. Program, PO Box 200195, 
Austin, TX 78720, phone (512) 338-3336, fax - 
(512) 338-3899, e-mail basmith@mcc.com. 

® Comp Euro 91, IEEE Int’l Conf. on 
Advanced Computer Tech., Reliable 
Systems, and Applications, May 13-17, Bo¬ 
logna, Italy. Cosponsors: IEEE Region 8 et al. 
Contact CompEuro 91 Conf. Secretariat, c/o 
Sercoop, via Crociali 2, 40138 Bologna, Italy, 
phone 39 (51) 300-811, fax 39 (51) 309-477; 
or Vito A. Monaco, Dip. di Elettronica Infor- 
matica E Sistemistica, Univ. di Bologna, Viale 
Risorgimento 2, 40136, Bologna, Italy, fax 39 
(51) 644-3073. 

Ada-Europe Athens 91 Conf., May 13-17, 

Athens. Cosponsors: Ada-Europe et al. Con¬ 
tact Z. Kaplanidis, Zita Tourist Club, 46 Vou- 
lis St., GR - 10558 Athens, Greece, phone 30 
(1) 323-9744/7, fax 30 (1) 324-1720. 

Sixth Goddard Conf. on Space Applications 
of Artificial Intelligence, May 14-15, Green- 
belt, Md. Sponsor: NASA. Contact Carl Hos- 
tetter, NASA Goddard Space Flight Center, 
Greenbelt, MD 20771, phone (301) 286-3150. 

North Am. Fuzzy Information Processing 
Soc. Workshop, May 15-17. Columbia, Mo. 
Contact Jim Keller, Electrical and Computer 
Eng., Univ. of Missouri — Columbia, Colum¬ 
bia, MO 65211, phone (314) 882-7339, fax 
(314) 882-0397. 

1991 Conf. on Artificial Intelligence in Pe¬ 
troleum Exploration and Production, May 


15-17, College Station, Texas. Contact Tech¬ 
nical Program Committee, CAIPEP, Petro¬ 
leum Eng. Dept., Texas A&M Univ., College 
Station, TX 77843-3116, phone (409) 845- 
6950, fax (409) 845-1307. 

ISSRE 91, Int’l Symp. on Software 
Reliability Eng., May 17-18, Austin, 
Texas. Cosponsors: IEEE Computer Soc. 
Technical Committee on Software Eng. and 
the Nat'l Aeronautics and Space Administra¬ 
tion. Contact Anneliese von Mayrhauser, 
Computer Science Dept., Illinois Inst, of 
Tech., SB236 C 10, West 31st St., Chicago, IL 
60616, phone (312) 567-3900, fax (708) 790- 
1826, e-mail csavm@karl.iit.edu. 

Workshop on Parallel and Distributed De¬ 
bugging, May 20-21, Santa Cruz, Calif. Co¬ 
sponsors: ACM, US Navy Office of Naval Re¬ 
search. Contact Bart Miller, Computer Sci¬ 
ence Dept., Univ. of Wisconsin, 1210 W. 
Dayton St., Madison, WI 53706, phone (608) 
263-3378, Internet bart@cs.wisc.edu. 

1991 IEEE Symp. on Research in Se- 
curity and Privacy, May 20-22, Oak¬ 
land, Calif. Sponsor: IEEE Computer Soc. 
Technical Committee on Security and Privacy. 
Contact Daniel Schnackenberg, Boeing, MS 
9P-64, PO Box 3999, Seattle, WA 98124, 
phone (206) 657-5595, e-mail 
schnackenberg @ dockmaster.ncsc.mil. 

Second Physical Design Workshop, May 20- 

22, Laurel Highlands, Pa. Sponsor: ACM 
SIGDA. Contact Mary Jane Irwin, Pennsylva¬ 
nia State Univ., Computer Science Dept., Uni¬ 
versity Park, PA 16802, phone (814) 865- 
1802, e-mail mji@guardian.cs.psu.edu; or 
Antun Domic, HL02-3J3, DEC, 77 Reed Rd., 
Hudson, MA 01749, e-mail domic@cadsys. 


ICDCS 91,11th Int’l Conf. on Dis- 
tributed Computing Systems, May 
20-24, Arlington, Texas. Contact Bill D. Car- 
roll, Computer Science Eng. Dept., Univ. of 
Texas at Arlington, Box 19015, Arlington, TX 
76019-0015, phone (817) 273-3787, fax (817) 
273-2548, e-mail carroll@evax.utarl.edu. 

SESAW, Fourth Software Eng. Stan- 
dards Application Workshop, May 
20-24, San Diego, Calif. Contact Vera V. Edel- 
stein, Nynex, 500 Westchester Ave., White 
Plains, NY 10604, phone (914) 683-2888. 

EKAW 91, Fifth European Knowledge Ac¬ 
quisition for Knowledge-Based Systems 
Workshop, May 20-24, Crieff, Scotland. 
Contact Duncan Smeed, Computer Science 
Dept., Univ. of Strathclyde, Livingstone Tow¬ 
er, 26 Richmond St., Glasgow G1 1XH, Scot¬ 
land, phone (041-552) 4400. 

SCAI 91, Third Scandinavian Conf. on Ar¬ 
tificial Intelligence, May 21-24, Roskilde, 
Denmark. Contact Brian Mayoh, Computer 
Science Dept., Aarhus Univ., Ny Munkegade, 
Bldg. 540, DK-8000 Aarhus C, Denmark, 
phone 45 (86) 127188, fax 45 (86) 135725, 
e-mail brian@daimi.aau.dk. 


City, Iowa. Contact Teodor Rus, Computer 
Science Dept., Univ. of Iowa, Iowa City, IA 
52242, phone (319) 335-0694, e-mail rus@ 
herky.cs.uiowa.edu. 

Melecon 91, Fifth Mediterranean Electro¬ 
technical Conf., May 22-24, Ljubljana, Yu¬ 
goslavia. Cosponsors: IEEE Region 8 Yugo¬ 
slavia Section et al. Contact Melecon 91 
Secretariat, Fakulteta za elektrotehniko, Trza- 
ska 25, 61001 Ljubljana, Yugoslavia, phone 
38 (61) 265-161, fax 38 (61) 264-990. 

Workshop on Interconnections With- 
VEY in High-Speed Digital Systems, May 
22-24, Santa Fe, N.M. Cosponsors: IEEE 
Comm. Soc. et al. Contact IEEE Lasers and 
Electro-Optics Soc., 445 Hoes Lane, PO Box 
1331, Piscataway, NJ 08855-1331, phone 
(908) 562-3896, fax (908) 562-1571. 

Computer Animation 91, May 22-25, Gene¬ 
va. Cosponsors: Computer Graphics Soc. Con¬ 
tact Nadia M. Thalmann, Mira Lab CUI, Univ. 
of Geneva, 12 rue du Lac, CH 1207, Geneva, 
Switzerland, phone 41 (22) 787-6581, fax 41 
(22) 735-3905, e-mail thalmann@uni2a.unige. 
ch. 


I 11 * * Symp. on Multiple-Valued 

Logic, May 26-29, Victoria, B.C., Can¬ 
ada. Contact D.M. Miller, Computer Science 
Dept., Univ. of Victoria, PO Box 1700, Victo¬ 
ria, B.C., Canada, V8W 2Y2, phone (604) 
721-7220, fax (604) 721-7292, e-mail dmill@ 
csr.uvic.cdn. 

ISCA 18, 18th Int’l Symp. on Com- 
sgy puter Architecture, May 26-30, 

Toronto. Cosponsor: ACM. Contact K.C. 
Smith, Univ. of Toronto, Electrical Eng. 

Dept., Toronto, Ont. M5S 1A4, Canada, 
phone (416) 978-5033. 

ICCI 91, Int’l Conf. on Computing and In¬ 
formation, May 27-29, Ottawa, Canada. 
Sponsors: Carleton Univ, Ottawa; Natural Sci¬ 
ences and Eng. Research Council of Canada. 
Contact Frank Fiala, School of Computer Sci¬ 
ence, Carleton Univ., Ottawa, Canada K1S 
5B6, phone (613) 788-4333, fax (613) 788- 
4334, e-mail icci@scs.carleton.ca. 

jgfe) Euro AISIC 91, May 27-31, Paris. 

Contact Gabriele Saucier, Inst. Nat’l 
Polytechnic de Grenoble/CSI, 46, avenue Fe¬ 
lix Viallet, 38031 Grenoble Cedex, France, 
phone 33 (9) 7657-4687. 

Fifth Israel Conf. on Computer Sys- 
terns and Software Eng., May 28-29, 

Herzlia, Israel. Sponsors: IEEE Computer 
Soc. Israeli Chapter et al. Contact M. Wino- 
kur, c/o ORTRA, PO Box 50432, Tel Aviv 
61500, Israel, phone 972 (3) 664-825, fax 972 
(3) 660-952. 

® 1991 IEEE Pacific Northwest Test 
Workshop, May 29-31, Eastsound, 
Wash. Contact Mani Soma, Univ. of Washing¬ 
ton, Electrical Eng. Dept., FT-10, Seattle, WA 
98195, phone (206) 685-3810, fax (206) 
543-3842. 
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Workshop on Directions in Automat- 
ed CAD-Based Vision, June 2-3, 

Maui, Hawaii. Contact Linda G. Shapiro, 
Computer Science and Eng. Dept., FR-35, 
Univ. of Washington, Seattle, WA 98195, 
phone (206) 543-2196, fax (206) 543-3842. 

® IEA/AIE 91, Fourth Int’l Conf. on In¬ 
dustrial and Eng. Applications of Ar¬ 
tificial Intelligence and Expert Systems, 
June 2-5, Kauai, Hawaii. Sponsors: ACM et 
al. Contact Moonis Ali, Univ. of Tennessee 
Space Inst., MS 15, B.H. Goethert Pkwy., Tul- 
lahoma, TN 37388-8897, phone (615) 455- 
0631, ext. 236, fax (615) 454-2354, e-mail 
alif@utsivl.bitnet. 

((£% ] Southwest Test Workshop, June 3-5, 

San Diego, Calif. Sponsor: IEEE Com¬ 
puter Soc. Technical Committee on Test Tech. 
Contact William R. Mann, Rockwell Int’l, MS 
503-200, 4311 Jamboree, Newport Beach, CA 
92660, phone (714) 833-4013, fax (714) 833- 


11th Int’l Conf. on Decision-Support Sys¬ 
tems, June 3-5, Manhattan Beach, Calif. 
Sponsor: Inst, for Management Sciences. Con¬ 
tact TIMS, 290 Westminster St., Providence, 
RI02903. 

First Golden West Int’l Conf. on Intelligent 
Systems, June 3-5, Reno, Nev. Sponsor: Int’l 
Soc. of Mini and Microcomputers. Contact 
Carl G. Looney, CS Dept., Univ. of Nevada, 
Reno, NV 89557, phone (702) 784-6927, 
e-mail looney@tahoe.unr.edu. 

Fifth Supercomputing Symp., June 3-5, Fre¬ 
dericton, N.B., Canada. Cosponsors: Canadian 
Special Interest Group on Supercomputing, 
Univ. of New Brunswick. Contact Virendra C. 
Bhavsar or Uday G. Gujar, Faculty of Com¬ 
puter Science, Univ. of New Brunswick, Fred¬ 
ericton, N.B., E3B 5A3, Canada, phone (506) 
453-4566, fax (506) 453-3566. 

CVPR 91, IEEE Computer Soc. Conf. 
on Computer Vision and Pattern Rec¬ 
ognition, June 3-7, Lahaina, Maui. Hawaii. 
Contact Shahriar Negahdaripour, Electrical 
Eng. Dept., Univ. of Hawaii at Manoa, 2540 
Dole St., Honolulu, HI 96822, e-mail 
shahriar@wiliki.eng.hawaii.edu. 

20th Mumps Users Group Meeting, June 3- 

7, New Orleans. Contact Mumps Users Group, 
4321 Hartwick Rd., Suite 100, College Park, 
MD 20740, phone (301) 779-6555, fax (301) 
779-7674. 

Symp. on Solid Modeling Foundations and 
CAD/CAM Applications, June 5-7, Austin, 
Texas. Sponsor: ACM SIGGraph. Contact 
Joshua Turner, CII 7015, RDRC, Rensselaer 
Polytechnic Inst., Troy, NY 12180-3590, 
phone (518) 276-6751, fax (518) 276-2702, 
e-mail jtumer@rdrc.rpi.edu. 

Second Eurographics Workshop on Object- 
Oriented Graphics, June 5-7, the Nether¬ 
lands. Sponsor: Dutch Center for Math, and 
Computer Science (CWI). Contact Marja 


Hegt, CWI, Kruislaan 413, 1098 SJ Amster¬ 
dam, the Netherlands, phone 31 (20) 592- 
4058, fax 31 (20) 592-4199, e-mail marja@ 
cwi.nl. 


/fljj IEEE Posix Open Systems Seminar, 
June 10-11, Washington, DC. Contact 
IEEE Standards Seminars, 445 Hoes Lane, PO 
Box 1331, Piscataway, NJ 08855-1331, phone 
(908) 562-3805. 


Rapid System Prototyping Workshop, June 
10-12, Raleigh, N.C. Contact Kenneth R. 
Anderson, Siemens Corp. Research, 755 Col¬ 
lege Rd. East, Princeton, NJ 08540, phone 
(609) 734-6550, e-mail kra@siemens.com. 


Parle 91, Conf. on Parallel Architectures 
and Languages Europe, June 10-13, Eind¬ 
hoven, the Netherlands. Cosponsors: Commis¬ 
sion of European Communities et al. Contact 
F. Stoots, Philips Research Labs, PO Box 
80.000, 5600 JA Eindhoven, the Netherlands, 
fax 31 (40) 744-758, e-mail stoots@dooma. 
prl.philips.nl. 

Summer 1991 Usenix Tech. Conf., June 10- 

14, Nashville, Tenn. Contact Usenix Conf. Of¬ 
fice, 22672 Lambert St., Suite 613, El Toro, 
CA 92630, phone (714) 588-8649, fax (714) 
588-9706. 


ISCAS 91, 24th IEEE Int’l Symp. on Cir¬ 
cuits and Systems, June 11-14, Singapore. 
Sponsor: IEEE Circuits and Systems Soc. 
Contact ISCAS 91 Secretariat, Comm. Int’l 
Associates, 44/46 Tanjong Pagar Rd., Singa¬ 
pore 0208, phone (65) 226-2823, fax (65) 
226-2877. 


yra SCM 3, Third Int’l Software Configu- 
nU' ration Management Workshop, June 
12-14, Trondheim, Norway. Cosponsors: 

ACM et al. Contact Reidar Conradi, Computer 
Systems and Telematics Div., Norwegian Inst, 
of Tech., N-7034 Trondheim, Norway, phone 
47 (7) 593-444; or Peter Feiler, Software Eng. 
Inst., Carnegie Mellon Univ., Pittsburgh, PA 
15213-3890, phone (412) 268-7790, e-mail 
phf@sei.cmu.edu. 


1991 ACM Symp. on Personal and Small 
Computers, June 12-14, Toronto. Cospon¬ 
sors: Nat’l Research Council of Canada et al. 
Contact Michael Bauer, Computer Science 
Dept., Middlesex College, Univ. of Western 
Ontario, London, Ont., Canada N6A 5B7, 
e-mail bauer@csd.uwo.ca or bauer@uwovax. 
bitnet. 


BISFAI 91, Bar-Ilan Symp. on the Founda¬ 
tions of Artificial Intelligence, June 16-19, 

Ramat Gan, Israel. Sponsor: Bar-Ilan. Contact 
Ariel Frank, BISFAI 91, Math and Computer 
Science Dept., Bar-Ilan Univ., Ramat Gan, Is¬ 
rael, e-mail ariel@bimacs.bitnet. 


DAC 91, 28th ACM/IEEE Design Au- 
tomation Conf., June 17-21, San Fran¬ 
cisco. Contact MP Associates, 7490 Club¬ 
house Rd., Suite 102, Boulder, CO 80301, 
phone (303) 530-4333. 


1991 ACM Int’l Conf. on Supercomputing, 
June 17-21, Cologne, Germany. Cosponsors: 
Gesellschaft filr Informatik et al. Contact Rue- 


diger Esser, FKA-ZAM, D-5170 Juelich, Ger¬ 
many, phone 49 (2461) 61-6588, fax 49 
(2461) 61-6656, e-mail zdv003@djukfal 1. 
bitnet. 

Eighth Int’l Conf. on Testing Computer 
Software, June 17-21, Washington, DC. 
Sponsor: Data Processing Management Assoc. 
Educational Foundation. Contact Genevieve 
Houston-Ludlam, Frontier Technologies, 190 
Admiral Cochran Dr., Suite 180, Annapolis, 
MD 21401, phone (301) 266-8244, fax (301) 
224-3840. 


29th Meeting of the Assoc, for Computa¬ 
tional Linguistics, June 18-21, Berkeley, 
Calif. Contact Don Walker, Bellcore, MRE 
2A379, 445 South St., Box 1910, Morristown, 
NJ 07960-1910, phone (201) 829-4312, e-mail 
walker@flash.bellcore.com or bellcore!walker. 

((fit CGI 91, Int’l Conf. on Computer 
N5Z Graphics, June 22-28, Cambridge, 
Mass. Cosponsors: Computer Graphics Soc., 
MIT. Contact Barbara Dullea, Ocean Eng. 
Dept., MIT Rm. 5-435, 77 Massachusetts 
Ave., Cambridge, MA 02139, fax (617) 253- 
8125, e-mail barbara@deslab.mit.edu. 


1991 IEEE Int’I Symp. on Information The¬ 
ory, June 23-28, Budapest, Hungary. Contact 
Anthony Ephremides, Electrical Eng. Dept., 
Univ. of Maryland, College Park, MD 20742, 
phone (301) 405-3641, arpanet tony@eng. 
umd.edu. 


ICANN 91, Int’l Conf. on Artificial Neural 
Networks, June 24-28, Espoo, Finland. Co¬ 
sponsors: IEEE Neural Networks Council, 
lnt’1 Neural Network Soc. Contact Congress 
Management Systems, PO Box 151, SF-00141 
Helsinki, Finland, phone 358 (0) 175-355, fax 
358(0) 170-122. 


ftTO FTCS 21, 21st Int’l Symp. on Fault- 
Tolerant Computing, June 25-27, 

Montreal. Sponsor: IEEE Computer Soc. 
Technical Committee on Fault-Tolerant Com¬ 
puting. Contact Vinod K. Agarwal, McGill 
Univ., Electrical Eng. Dept., 3480 University 
St., Montreal, Que., Canada H3A 2A7, phone 
(514) 398-7136, fax (514) 398-4470, e-mail 
agarwal@spock.ee.mcgill.ca. 


Compass 91, Sixth Conf. on Computer As¬ 
surance Systems Integrity, Software Safety, 
and Process Security, June 25-27, Gaithers¬ 
burg, Md. Cosponsors: IEEE Aerospace and 
Electronics Soc., IEEE Nat’l Capital Area 
Council. Contact Dolores R. Wallace, Nat’l 
Inst, of Standards and Tech., Gaithersburg, 
MD 20899, phone (301) 975-3340, e-mail 
wallace@swe.ncsl.nist.gov. 

First Int’l Conf. on Artificial Intelligence in 
Design, June 25-27, Edinburgh, Scotland. 
Contact Helen Hodge or Tom Whiting, Butter- 
worth Scientific, Westbury House, Bury 
Street, Guildford, Surrey, GU2 5BH, UK, 
phone (0483) 300-966, fax (0483) 301-563. 


Fifth Int’l Conf. on Logic Programming, 
June 25-28, Paris. Cosponsors: Assoc, of 
Logic Programming et al. Contact Inst. Nat’l 
de Recherche en Informatique et en Automa- 
tique (INRIA), Service des Relations Ex- 
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terieures, Domaine de Voluceau — Rocquen- 
court, BP 105, 78153 Le Chesnay Cedex, 
France; phone 33 (1 >39-63-55-00, fax 33 (1) 
39-63-56-38, e-mail iclp@minos.inria.fr. 

ICAIL 91, Third Int’l Conf. on Artificial 
Intelligence and Law, June 25-28, Oxford, 
UK. Cosponsors: Soc. for Computer and Law 
(UK) et al. Contact Carole Hafner, College of 
Computer Science, Northeastern Univ., Bos¬ 
ton, MA 02115, e-mail hafner@corwin.ccs. 
northeastern.edu; or Richard Susskind, Ma¬ 
sons, Solicitors, 30 Aylesbury St., London 
EC1R OER, UK, phone 44 (071) 490-4000, 
fax 44 (071) 490-2545. 


Arith 10, 10th Symp. on Computer 
Arithmetic, June 26-28, Grenoble, 
France. Cosponsors: ACM et al. Contact Jean- 
Michel Muller, Lab. LIP-IMAC, Ens. Lyon, 
69364 Lyon Cedex 07, France, phone 33 (72) 
72-8229. 


Second Int’l Conf. on Local Communica¬ 
tion Systems, June 26-28, Palma, Spain. 
Sponsor: Int’l Federation for Information Pro¬ 
cessing. Contact Ramon Puigjaner, Univ. de 
les Hies Balears, Carretera de Valldemossa, 
km. 7.6, 07071 Palma, Spain, phone 34 (71) 
207111, fax 34 (71) 758061 or 200741, e-mail 
dmilan91@ps.uib.es. 

Third Int’l Conf. on Software Eng. and 
Knowledge Eng., June 27-29, Skokie, Ill. 
Sponsors: Knowledge Systems Inst, et al. 
Contact W.D. Hurley, Computer Science 
Dept., Alumni Hall, Univ. of Pittsburgh, Pitts¬ 
burgh, PA 15260, phone (412) 624-8843, 
e-mail hurley@cs.pitt.edu. 

Sixth IEEE Conf. on Structure in Complex¬ 
ity Theory, June 30-July 3, Chicago. Contact 
N. Immerman, Computer and Information Sci¬ 
ence Dept., Univ. of Massachusetts, Amherst, 
MA 01003, e-mail immerman@cs.umass.edu. 


July 1991 


IEE Bicentennial Conf. on Computing, July 
1-3, London. Contact Conf. Services, Institu¬ 
tion of Electrical Engineers, Savoy Place, 
London WC2R 0BL, UK, phone 44 (71) 240- 
1871, fax 44 (71) 240-7735. 


ftijl CAR 91, Fifth Int’l Symp. on Corn¬ 
'll?' puter-Assisted Radiology, July 3-6, 

Berlin. Sponsor; Technical Univ. of Berlin. 
Contact Heinz U. Lemke, Inst, for Technical 
Computer Science, Sekr CG-FR3-3, Franklin- 
strasse 28-29, D-1000, Berlin 10, Germany, 
phone 49 (30) 314-73100; or Michael H. 
Rhodes, Toshiba America MRI, 280 Utah 
Ave., South San Francisco, CA 94080, phone 
(415) 875-2909. 

Operating Systems of the 90s and Be- 
yond, July 8-12, Dagstuhl, Germany. 
Contact Arthur I. Karshmer, New Mexico 
State Univ., Computer Science Dept., PO Box 
30001, Dept. 3CU, Las Cruces, NM 88003- 
0001, phone (505) 646-2312, fax (505) 646- 
6218. 


Second Int’l Conf. on Industrial and Ap¬ 
plied Math., July 8-12, Washington, DC. 
Contact Soc. for Industrial and Applied Math. 
Conf. Coordinator, Dept. CC0590, 3600 Uni¬ 
versity City Science Center, Philadelphia, PA 
19104-2688, phone (215) 382-9800, fax (215) 
386-7999, e-mail siamconfs@wharton.upenn. 

ICGA 91, Fourth Int’l Conf. Symp. on Ge¬ 
netic Algorithms, July 13-16, San Diego, 
Calif. Contact Richard K. Belew, Computer 
Science and Eng. Dept., C-014, Univ. of Cali¬ 
fornia at San Diego, La Jolla, CA 92093, 
e-mail rik@cs.ucsd.edu. 


AAAI 91, Ninth Nat’l Conf. on Artificial In¬ 
telligence, July 14-19, Anaheim, Calif. Spon¬ 
sor: Am. Assoc, for Artificial Intelligence. 
Contact AAAI 91, 445 Burgess Dr., Menlo 
Park, CA 94025-3496, phone (415) 328-3123, 
fax (415) 321-4457, e-mail ncai@aaai.org. 

IAAI 91, Third Conf. on Innovative Appli¬ 
cations of Artificial Intelligence, July 15-17, 

Anaheim, Calif. Sponsor: Am. Assoc, for Ar¬ 
tificial Intelligence. Contact IAAI 91, AAAI, 
445 Burgess Dr., Menlo Park, CA 94025- 
3496, phone (415) 328-3123, fax (415) 321- 
4457, e-mail iaai@aaai.org. 

Second Int’l Information Research Conf., 
July 15-18, Cambridge, UK. Sponsors: British 
Library Research and Development Dept, 
Univ. of Pittsburgh. Contact Karen Merry, 
British Library R&D Dept., 2 Sheraton St., 
London W1V 4BH, UK, phone 44 (071) 323- 
7050, fax 44 (071) 323-7251. 


JWCC 6, Sixth Joint Workshop on Com¬ 
puter Comm., July 17-19, Kitakyushu, Fuku¬ 
oka, Japan. Contact Makoto Takizawa, Infor¬ 
mation and Systems Eng. Dept., Tokyo Denki 
Univ., Hatoyama, Saitama 350-03, Japan, 
phone 81 (492) 96-2911 ext. 2406, fax 81 
(492) 96-6185, e-mail taki@takilab.k.dendai. 
ac.jp. 


SIGGraph 91, July 30-Aug. 1, Las Ve- 

gas. Sponsor: ACM. Contact Assoc, for 
Computing Machinery, 11 W. 42nd St., New 
York, NY 10036, phone (212) 869-7440. 


August 1991 


tgfjjs Crypto 91, Aug. 11-15, Santa Barbara, 

Calif. Cosponsors: Int’l Assoc, for 
Cryptologic Research et al. Contact Burt 
Kaliski, Crypto 91, RSA Data Security, 10 
Twin Dolphin Dr., Redwood City, CA 94065, 
phone (415) 595-8782, fax (415) 595-1873, 
Internet: burt@rsa.com. 

Hot Chips III Symp., Aug. 26-27, 

^57 Stanford, Calif. Sponsor: IEEE Comput¬ 
er Soc. Technical Committee on Microproces¬ 
sors and Microcomputers. Contact Martin 
Freeman, Philips Research Labs, Signetics MS 
02, 811 E. Arques Ave., Sunnyvale, CA 
94086, phone (408) 991-3591, fax (408) 991- 
4077, e-mail mfreeman@sierra.stanford.edu; 
or Melissa Anderson, Silicon Graphics, 2011 
N. Shoreline Blvd., PO Box 7311, Mountain 


View, CA 94039-7311, phone (415) 335-1565, 
fax (415) 965-7651, e-mail mda@sgi. com. 


Tencon 91, 1991 IEEE Region 10 
Conf., Aug. 26-30, New Delhi, India. 
Contact H.L. Bajaj, B-101 Hillview Apts., Va- 
sant Aihar, New Delhi 110057, India, phone 
91 (11) 36-0412, fax 91 (11) 36-1018; or A.L. 
Lakshminarasimhan, AT&T Bell Labs, 480 
Red Hill Rd„ No. HR 2E030, Middletown, NJ 
07748, phone (201) 615-4524. 


£fjj\ SSD 91, Second Symp. on Large Spa- 
tial Databases, Aug. 28-30, Zurich, 
Switzerland. Contact Hans-J. Schek, Inst, fur 
Information Systeme, Eth Zentrum, CH-8092 
Zurich, Switzerland, phone 41 (1) 254-7240, 
fax 41 (1) 262-3973, e-mail schek@inf.ethz. 
ch. 


September 1991 

® VLDB 91, 17th Int’l Conf. on Very 
Large Data Bases, Sept. 3-6, Barcelo¬ 
na, Spain. Sponsors: IEEE Computer Soc. 
Technical Committee on Data Eng. et al. Con¬ 
tact Guy M. Lohman, IBM Almaden Research 
Center, Dept. K55, Bldg. 801, 650 Harry Rd., 
San Jose, CA 95120-6099, Internet lohman@ 
ibm.com, Bitnet lohman@almaden. 

(jjijj) Compsac 91, 15th Int’l Computer 
Software and Applications Conf., 
Sept. 11-13, Tokyo. Cosponsor: Information 
Processing Soc. of Japan. Contact Stephen S. 
Yau, Univ. of Florida, CIS Dept., Rm. 301, 
Gainesville, FL 32611, phone (904) 335-8006 
or (904) 392-1212, fax (904) 392-1220, e-mail 
yau@cis.ufl.edu. 

First Int’l Workshop on the Econom- 
vfty ics of Design and Test, Sept. 23-25, 

Austin, Texas. Sponsor: ACM. Contact Mag- 
dy Abadir, MCC CAD Program, 3500 W. Bal- 
cones Center Dr„ Austin, TX 78759, phone 
(512) 338-3611, fax (512) 338-3600; or A.P. 
Ambler, Brunei Univ., Dept, of Electrical 
Eng. and Electronics, Uxbridge, Middx, UB8 
3PH, UK, phone (44) 895-74000, fax (44) 
895-58728. 

(jjjji ASIC 91, Fourth IEEE Int’l Applica- 
tion-Specific Integrated Circuits 
Conf., Sept. 23-27, Rochester, N.Y. Sponsor: 
IEEE Rochester Section. Contact Lynne M. 
Engelbrecht, ASIC 91, 170 Mt. Read Blvd., 
Rochester, NY 14611, phone (716) 328-2310, 
fax (716) 436-9370. 

Pacific Rim Int’l Symp. on Fault- 
Tolerant Systems, Sept. 26-27, Ka¬ 
wasaki, Japan. Sponsor: Inst, of Electrical, In¬ 
formation, and Comm. Eng. Contact Sachio 
Naito, Electrical Eng. Dept., Nagaoka Univ. 
of Tech., 1603-1 Kamitomioka, Nagaoka, Ni¬ 
igata, 940-21, Japan, phone 81 (258) 46-6000, 
ext. 5110, fax 81 (258) 46-6506. 

(ifjj) IEEE/ACM Int’l Conf. on Developing 
and Managing Expert System Pro¬ 
grams and Projects, Sept. 30-Oct. 2, Wash¬ 
ington, DC. Contact Jerald Feinstein, Mitre, 
7325 Colshire Dr., McLean, VA 22102, phone 
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(703) 883-6236, fax (703) 821-0701; or Larry 
Medsker, Computer Science and Information 
Systems Dept., American Univ., Washington, 
DC 20016. 

10th Symp. on Reliable Distributed 
Systems, Sept. 30-Oct. 2, Pisa, Italy. 
Contact Luca Simoncini, IEI-CNR, Via S. 
Maria 46, 56100 Pisa, Italy, phone 39 (50) 
553-159, fax 39 (50) 554-342; or Ozalp 
Babaoglu, Dip. di Matematica, Univ. di 
Bologna, Piazza di Porta S. Donato, 5, 40127 
Bologna, Italy, phone 39 (51) 354-430, fax 39 
(51) 354-490, e-mail ozalp@dm.unibo.it. 

tfjj!) First Int’l Conf. on Document Analy- 
NS?' sis and Recognition, Sept. 30-Oct. 2, 

Saint-Malo, France. Cosponsors: Assoc. Fran- 
caise pour la Cybernetique Economique et 
Technique et al. Contact Guy Lorette, IRISA- 
Campus Universitaire de Beaulieu, 35042 
Rennes Cedex, France, phone (33) 9936-2000, 
fax (33) 9938-32. 


October 1991 

IEEE Workshop on Visual Motion, 
Oct. 6-9, Princeton, N.J. Contact Peter 
Burt, David Sarnoff Research Center, 201 
Washington Rd„ Princeton, NJ 08540, e-mail 
burt@vision.samoff.com. 

CSEE 91, Fifth Conf. on Software 
Eng. Education, Oct. 7-8, Pittsburgh. 
Sponsor: Software Eng. Inst. Contact James E. 
Tomayko, SEI, Carnegie Mellon Univ., 4500 
Fifth Ave., Pittsburgh, PA 15213-3890, phone 
(412) 268-6806, fax (412) 268-5758, e-mail 
jet@sei.cmu.edu. 

11th IEEE Symp. on Mass Storage 
Systems, Oct. 7-10, Monterey, Calif. 
Sponsor: IEEE Computer Soc. Technical 
Committee on Mass Storage Systems and 
Tech. Contact Bernard T. O’Lear, NCAR, PO 
Box 3000, Boulder, CO 80307, phone (303) 
497-1268, fax (303) 497-1137. 


yro First Int’l Conf. on Artificial Intelli- 
gence Applications on Wall St., Oct. 
9-11, New York City. Sponsor: Polytechnic 
Univ., Brooklyn. Contact Mary Bianchi, Poly¬ 
technic Univ., 333 Jay St., Brooklyn NY 
11201, phone (718) 260-3360, fax (718) 260- 
3136. 

(fra Int’l Workshop on Visual Languages, 
Oct. 9-11, Kobe, Japan. Cosponsors: 
Hiroshima Univ., Univ. of Pittsburgh. Contact 
Shi-Kuo Chang, Computer Science Dept., 
Univ. of Pittsburgh, Pittsburgh, PA 15260, 
phone (412) 624-8423, fax (412) 624-8465. 

Workshop on Experimental Distrib- 
uted Systems, Oct. 12, Huntsville, Ala. 
Contact Raif M. Yanney, TRW, 1 Space Park, 
DH2/2328, Redondo Beach, CA 90278, phone 
(213) 764-6033. 

® RIDT 91, Second Int’l Workshop on 
Raster Imaging and Digital Typogra¬ 
phy, Oct. 14-15, Boston. Cosponsor: Univ. of 
Massachusetts. Contact Robert A. Morris, 


Math, and Computer Science Dept., Univ. of 
Massachusetts at Boston, Harbor Campus, 
Boston, MA 02125-3393, phone (617) 287- 
6466, e-mail ridt91-request@cs.umb.edu. 

/gfej ICCD 91, IEEE Int’l Conf. Symp. on 
Computer Design, Oct. 14-16, Cam¬ 
bridge, Mass. Cosponsors: IEEE Computer 
Soc. and IEEE Circuits and Systems Soc. 
Contact ICCD 91, IEEE Computer Soc., 1730 
Massachusetts Ave. NW, Washington, DC 
20036-1903, phone (202) 371-1013. 

16th Conf. on Local Computer Net- 
works, Oct. 14-17, Minneapolis, Minn. 
Cosponsor: IEEE Computer Soc. Technical 
Committee on Computer Comm. Contact 
James F. Mollenauer, Technical Strategy As¬ 
sociates, 37 Silver Birch Rd., Newton, MA 
02168, phone and fax (617) 244-0077. 

Conf. on Software Maintenance, Oct. 
14-17, Sorrento, Italy. Cosponsor: 

IEEE. Contact Vaclav Rajlich, Computer Sci¬ 
ence Dept., Wayne State Univ., Detroit, MI 
48202, phone (313) 577-5423, fax (313) 577- 
6868, e-mail vtr@cs.wayne.edu; John Mun¬ 
son, Computer Science Dept., Univ. of West 
Florida, Pensacola, FL 32514; or Malcolm 
Munro, Centre for Software Maintenance, 
Univ. of Durham, Durham, DH1 3LE, En¬ 
gland, phone 44 (091) 374-2634, e-mail 
malcolm.munro@uk.ac.durham. 

jjrflj!) Visualization 91, Oct. 22-25, San Di- 
'^SP' ego, Calif. Sponsor: IEEE Computer 
Soc. Technical Committee on Computer 
Graphics. Contact Bruce Brown, Oracle, 500 
Oracle Pkwy., MD 40P12, Redwood Shores, 
CA 94065, phone (415) 726-0983, fax (415) 
506-7200; or Gregory M. Nielson, Computer 
Science Dept., Arizona State Univ., Rural 
Road and University, Tempe, AZ 85287-5406, 
phone (602) 965-2785. 

Sixth Int’l Workshop on Software 
Specification and Design, Oct. 25-26, 

Como, Italy. Contact C. Ghezzi, Dip. di 
Elettronica, Politecnico di Milano, Piazza Le¬ 
onardo Da Vinci 32, 20133 Milano, Italia, 
e-mail relett24@imipoli.bitnet; or Jean-Pierre 
Finance, CRIN, Campus Scientifique, BP 239 
54000 Nancy, France, e-mail finance@loria. 
crin.fr. 

ILPS 91, Int’l Logic Programming 
Symp., Oct. 28-31, San Diego, Calif. 
Sponsor: Assoc, of Logic Programming. Con¬ 
tact Kenneth Kahn or Vijay Saraswat, Xerox 
PARC, 3333 Coyote Hill Rd„ Palo Alto, CA 
94304, Kahn’s phone (415) 494-4390, Saras- 
wat’s phone (415) 494-4747, fax (415) 494- 
4334, e-mail ilps91@parc.xerox.com. 

ITC 91, Int’l Test Conf., Oct. 28-Nov. 

^85' 1, Nashville, Tenn. Cosponsor: IEEE 
Philadelphia Section. Contact Doris Thomas, 
PO Box 264, Mt. Freedom, NJ 07970, phone 

(201) 895-5260, fax (201) 896-7265; or IF.F.F. 
Computer Soc., 1730 Massachusetts Ave. 

NW, Washington, DC 20036-1903, phone 

(202) 371-1013. 


30-Nov. 2, Ankara, Turkey. Sponsor: Bilkent 
Univ., IEEE Turkey Chapter. Contact Mehmet 
Baray, Bilkent Univ., Computer Eng. and In¬ 
formation Sciences Dept., Bilkent 06533 An¬ 
kara, Turkey, phone (90) 4-266-4133, fax 90 
(4) 266-4127, e-mail iscis@trbilun.bitnet. 


November 1991 

25th Asilomar Conf. on Signals, Sys- 

terns, and Computers, Nov. 4-6, Pacif¬ 
ic Grove, Calif. Sponsors: Naval Postgraduate 
School, San Jose State Univ. Contact Frederic 
J. Harris, Electrical and Computer Eng. Dept., 
San Diego State Univ., San Diego, CA 92182- 
0190, (619)594-6162. 

TAI 91, Third IEEE Computer Soc. 
N5^ Conf. on Tools for Artificial Intelli¬ 
gence, Nov. 5-8, San Jose, Calif. Contact 
Benjamin Wah, Coordinated Science Lab, MC 
228, Univ. of Illinois, 1101 W. Springfield 
Ave., Urbana, IL 61801-3082, phone (217) 
333-3516, fax (217) 244-1764, e-mail wah% 
aquinas@cso.uicu.edu; or Nikolaus G. Bour- 
bakis, 4138 Moonflower Ct., San Jose, CA 
95135, phone (408) 270-3455. 

^ ICCAD 91, IEEE Int’l Conf. on Com- 
^P' puter-Aided Design, Nov. 11-14, Santa 
Clara, Calif. Cosponsor: IEEE Circuits and 
Systems Soc. Contact ICCAD 91 Secretary, 
MP Associates, 7490 Clubhouse Rd., Suite 
102, Boulder, CO 80301, phone (303) 530- 
4562. 

jjjjS) Micro 24, 24th ACM/IEEE Int’l 

Symp. and Workshop on Microarchi¬ 
tecture, Nov. 18-20, Albuquerque, N.M. Con¬ 
tact Yashwant K. Malaiya, Computer Science 
Dept., Colorado State Univ., Fort Collins, CO 
80523, phone (303) 491-7031, fax (303) 491- 
2293, e-mail malaiya@ravi.cs.colostate.edu. 

I ^f^ l Supercomputing 91, Nov. 18-22, Albu- 
vs? querque, N.M. Cosponsor: ACM. Con¬ 
tact Raymond L. Elliott, Computing and 
Comm. Div., MS B260, Los Alamos Nat’l 
Lab, Los Alamos, NM 87545, phone (505) 
667-1449, fax (505) 665-4361, e-mail 
rle@lanl.gov; or Supercomputing 91, IEEE 
Computer Soc., 1730 Massachusetts Ave. 

NW, Washington, DC 20036-1903, phone 
(202) 371-1013. 


December 1991 


»n) Third Int’l Symp. on Parallel and 

Distributed Processing, Dec. 1-5, Dal¬ 
las. Contact Behrooz Shirazi, Univ. of Texas 
at Arlington, Computer Science Eng. Dept., 
Box 19015, Arlington, TX 76019-0015, phone 
(817) 273-3605, fax (817) 273-2548, e-mail 
shirazi@evax.utarl.edu. 

(jji) 12th IEEE Symp. on Real-Time Sys- 
^SP' terns, Dec. 3-6, San Antonio, Texas. 
Sponsor: IEEE Computer Soc. Technical 
Committee on Real-Time Computing. Contact 
Jane S.W. Liu, Computer Science Dept, Univ. 
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of Illinois, 1304 W. Springfield Ave., Urbana, 
IL 61801, phone (217) 333-0135, e-mail 
janeliu@cs.uiuc.edu. 


CALL FOR PAPERS 


Int’l Conf. on Parallel and Distribut- 
ed Information Systems, Dec. 4-6, Mi¬ 
ami Beach, Fla. Cosponsors: IEEE Computer 
Soc. et al. Contact Amit Sheth, Bellcore, 1J- 
210, 444 Hoes Ln., Piscataway, NJ 08854, 
phone (908) 699-3300, fax (908) 699-9011, 
e-mail amit@ctt.bellcore.com. 

1991 Winter Simulation Conf., Dec. 
8-11, Phoenix, Ariz. Sponsor: ACM. 
Contact Robert Crain, Wolverine Software, 

41 15 Annandale Rd., Suite 200, Annandale, 
VA 22003. 

World Congress on Expert Systems, 
Dec. 16-19, Orlando, Fla. Cosponsors: 
Int’l Assoc, of Knowledge Engineers et al. 
Contact World Congress on Expert Systems, 
c/o Congress Secretariat, Congrex (USA), 

Inc., 7315 Wisconsin Ave., Suite 404E, Be- 
thesda, MD 20814, phone (301) 469-3355, fax 
(301)469-3360. 


January 1992 


frfjj) Fifth Int’l Conf. on VLSI Design, Jan. 

4-7, Bangalore, India. Sponsor: VLSI 
Soc. of India et al. Contact A. Laha, Cadence 
Design Systems, Advanced CAE Division, 2 
Lowell Research Center Dr., Lowell, MA 
01852-4995, phone (508) 458-1900; or L.M. 
Patnaik, Computer Science and Automation, 
Indian Inst, of Science, Bangalore, 560012, 
India, phone 91 (812) 342-451. 

Hawaii Int’l Conf. on Systems Sci- 
ences, Jan. 7-10, Koloa, Hawaii. Co¬ 
sponsors: IEEE, ACM. Contact Luqi, Comput¬ 
er Science Dept, Naval Postgraduate School, 
Monterey, CA 93940, phone (408) 646-2468. 


February 1992 


Eighth Int’l Conf. on Data Eng., Feb. 

W* 3-7, Phoenix, Ariz. Contact Nick J. Cer- 
cone, Center for Systems Sciences, Simon 
Fraser Univ., Burnaby, B.C., Canada V5A 1S6, 
phone (604) 291-3229, e-mail nick@cs. sfu.ca. 

® Compcon Spring 92, Feb. 24-28, San 

Francisco. Contact Compcon Spring 92, 
IEEE Computer Soc., 1730 Massachusetts 
Ave. NW, Washington, DC 20036-1903, 
phone (202) 371-1013. 


March 1992 


(frjj) Int’l Symp. on Parallel Processing, 
'SZ' Mar. 30-Apr. 2, Beverly Hills, Calif. 
Contact Larry H. Canter, Computer Systems 
Approach, 1140 S. Raymond Ave., Suite B, 
Fullerton, CA 92631, phone (714) 738-3414, 
fax (714) 738-3470. 


Call for articles and referees for Computer 


Computer seeks articles for 
inclusion in upcoming special 
issues. 

Document Image Analysis Sys¬ 
tems is the theme planned for the 
June 1992 issue. Manuscripts report¬ 
ing survey, original research, design 
and development, and applications of 
document image analysis are sought 
immediately. See p. 109 of the March 
1991 issue for complete information. 

A 300-word abstract of each manu¬ 
script must be submitted by May 1, 
1991; 14 copies of the complete manu¬ 
script are due by July 1, 1991; notifi¬ 
cation of decisions is set December 1, 
1991; and the deadline for submittal of 
the final version of each manuscript is 
February 1,1992. 

Submissions and questions should 
be directed to Rangachar Kasturi, Elec¬ 
trical and Computer Engineering De¬ 
partment, Pennsylvania State University, 
University Park, PA 16802, phone (814) 
863-4254, e-mail kasturi@cmpe.psu. 
edu; or Lawrence O’Gorman, Room 3D- 
455, AT&T Bell Labs, Murray Hill, NJ 
07974, phone (201) 582-7262, e-mail 
log @ research .att.com. 

Wafer Scale Integration: Architec¬ 
tures and Algorithms will be the 
theme of the April 1992 issue. See p. 

109 of the February 1991 issue for 
complete details. 

A 300-word abstract of each manu¬ 
script is due not later than May 1, 

1991. Twelve copies of each complete 
manuscript are due by June 15,1991. 
Notification of decisions is set October 
1,1991, and the deadline for submit¬ 


ting the final version of the manuscript 
is December 1, 1991. 

Submissions and questions should 
be directed to W. Kent Fuchs, Center 
for Reliable and High-Performance 
Computing, Coordinated Science Labo¬ 
ratory, University of Illinois at Urbana- 
Champaign, 1101 W. Springfield Ave., 
Urbana, IL 61801, phone (217) 333- 
9731, fax (217) 244-1764, e-mail 
fuchs@crhc.uiuc.edu. Questions can 
also be directed to Earl Swartzlander, 
Department of Electrical and Computer 
Engineering, ENS Building, Room 517, 
University of Texas at Austin, Austin, 
TX 78712, phone (512) 471-5923. 

Computer Architectures for Intelli¬ 
gent Systems has been selected as 
the theme for the special May 1992 is¬ 
sue. Manuscripts are sought reporting 
survey, original research, design and 
development, and applications of multi- 
media technology in the following areas: 

• Architectures 

• Languages 

• Dependable operating systems 

• Communication schemes for intelli¬ 
gent systems, and 

• Performance analysis. 

Submit 12 copies of the full manu¬ 
script by June 1,1991, to Jayantha 
Herath, Dept, of Electrical and Com¬ 
puter Engineering, Drexel Univ., Phila¬ 
delphia, PA 19104, phone (215) 895- 
6758, fax (215) 895-1695, e-mail 
jheraz@ocs.drexel.edu. Notification of 
decisions is set for November 1, 1991, 
and the final version of the manuscript 
is due January 1,1992. 


For submittal to Computer, manuscripts must not have been previously 
published or currently submitted for publication elsewhere. Each manu¬ 
script should be no more than 32 typewritten, double-spaced pages long, 
including all text, figures, and references. Each of the 12 copies submitted 
should include a cover page that contains the title of the article, the full 
name(s) and affiliation(s) of the author(s), complete postal and electronic 
address(es) of all the authors as well as their telephone and fax numbers, 
a 300-word abstract, and a list of keywords identifying the central issues of 
the manuscript’s contents. The final manuscript should be approximately 
8,000 words in length and contain no more than 12 references. 

If you are willing to review articles for any of these special issues, 
please send a note listing your research interests to one of the guest edi¬ 
tors listed for the particular issue or to Jon T. Butler, editor-in-chief of 
Computer, at the Department of Electrical and Computer Engineering, Na¬ 
val Postgraduate School, Code EC/Bu, Monterey, CA 92943-5004, phone 
(408) 646-3299 or (408) 646-3041, fax (408) 646-2760, Internet butler@ 
ece.nps.navy.mil. 
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(£g) IEEE Micro invites authors to submit 
general-interest and theme issue papers 
for publication in 1992 issues. Themes include 
European industry, DSPs, associate memories 
and processors, and ICs for HDTV. Submit six 
copies of each paper to Editor-in-Chief Dante 
Del Corso, Dipartimento di Elettronica, Po- 
litecnico di Torino, C.so Duca degli Abruzzi, 
24, 10129 Torino, Italy, phone 39 (11) 556- 
7244, Compmail delcorso.d, Internet delcorso 
@pol88B.to.cnr.it, Bitnet de!corso@itopoli. 
For author guidelines, contact Ava Marie Ful¬ 
ton at (714) 821-8380. 


Int’l J. of Computer Simulation will begin 
quarterly publication this spring and seeks 
manuscripts on computer simulation, theory, 
and applications. Publisher: Ablex. Submit 
four copies of paper to G.W. Zobrist, Comput¬ 
er Science Dept, Univ of Missouri at Rolla, 
Rolla, MO 65401, phone (314) 341-4836, fax 
(314) 341-4501, e-mail c2816@umrvmb.umr. 


Int’l J. of Applied Intelligence seeks research 
and bibliographic papers and book reviews. 
Publisher: Kluwer. For author instructions and 
further information, contact Karen S. Cullen, 
Kluwer Academic Publishers, 101 Philip Dr., 
Norwell, MA 02061, phone (617) 871-6300, 
fax (617) 871-6528, e-mail karen@ world.std. 


16th Conf. on Local Computer Net- 
works: Oct. 14-17, 1991, Minneapolis, 
Minn. Cosponsor: IEEE Computer Soc. Tech¬ 
nical Committee on Computer Comm. Submit 
five copies of full paper by Apr. 19,1991, 
and camera-ready version by Aug. 2,1991, to 
James F. Mollenauer, Technical Strategy As¬ 
sociates, 37 Silver Birch Rd., Newton, MA 
02168, phone and fax (617) 244-0077. 


Sixth Conf. on Measurement, Modeling, 
and Evaluation of Computer Systems: Sept. 
18-20, 1991, Munich, Germany. Cosponsors: 
Gesellschaft fur Informatik et al. Submit six 
copies of short paper by Apr. 20,1991, to 
Axel or Fritz Lehmann, Fakultat fur Informa¬ 
tik, Univ. der Bundeswehr Miinchen, Wemer- 
Heisenberg-Weg 39, D-8014 Neubiberg, Ger¬ 
many, phone 49 (89) 6004-2648, fax 49 (89) 
6004-3560. 


15th Western Educational Computing 
Conf.: Nov. 21-22, 1991, Los Angeles. Spon¬ 
sor: Calif. Educational Computing Consor¬ 
tium. Submit two copies of original paper by 
Apr. 21,1991, to Gary Penders, Dodd Hall, 
UCLA, Los Angeles, CA 90024. 

Fourth Int’l Workshop on Protocol Test 

Systems: Oct. 15-17, 1991, Leidschendam, 
the Netherlands. Sponsors: Int’l Federation for 
Information Processing, PTT Research. Sub¬ 
mit full paper or position statement by Apr. 

22,1991, to Jan Kroon, PTT Research, PO 
Box 421, 2260 AK Leidschendam, the Nether¬ 
lands, phone 31 (70) 332-6357, e-mail j_kroon 
@ pttml.nl. 

Compugraphics 91, First Int’l Conf. on 
Computational Graphics and Visualization 
Techniques: Sept. 16-20, 1991, Sesimbra, 
Portugal. Cosponsors: SIGGraph et al. Submit 


abstract by Apr. 26, 1991, and final paper by 
July 31, 1991, to Compugraphics 91, c/o 
Harold P. Santo, Civil Eng. Dept., Inst, of 
Eng., Technical Univ. of Lisbon, Av. Rovisco 
Pais, 1096 Lisboa Codex, Portugal, phone 351 
(1) 801-579, fax 351 (1) 897-650, e-mail 
dl663@ eta.ist.rccn.pt. 

Fourth Int’l Symp. on Artificial Intelli¬ 
gence: Nov. 13-15, 1991, Cancun, Mexico. 
Sponsor: Inst. Tech, de Estudios Superiores de 
Monterrey. Submit five copies of paper by 
Apr. 30, 1991, and final version by July 15, 
1991, to Hugo Terashima, Centro de Inteli- 
gencia Artificial, ITESM, Ave. Eugenio Garza 
Sada No. 2501, Col. Tecnologico, CP 64849 
Monterrey, N.L. Mexico, phone 52 (83) 58- 
2000, ext. 5134, fax 52 (83) 58-1400, e-mail 
isai@tecmtyvm.bitnet. 

ICSQ 1, First Int’l Conf. on Software Qual¬ 
ity: Oct. 6-9, 1991, Dayton, Ohio. Cospon¬ 
sors: Am. Soc. for Quality Control Software 
Division and Dayton Section. Submit four 
copies of 300-word abstract by Apr. 30, 1991, 
to John Lowe, LCS SQA, 4020 Executive Dr., 
Dayton, OH 45430, phone (513) 429-6458, 
fax (513) 429-6368. 

Int’l J. on Pattern Recognition and Artificial 
Intelligence plans a special issue on reason¬ 
ing, searching, and solving problems. Pub¬ 
lisher: World Scientific. Submit four copies of 
full paper by Apr. 30, 1991, to Nikolaus G. 
Bourbakis, 4138 Moonflower Ct., San Jose, 

CA 95135, phone (408) 270-3455, fax (408) 
256-6760. 


CASE on Trial II Conf.: Mar. 22-24, 1992, 
Cambridge, England. Sponsor: British Com¬ 
puter Soc. Submit 1,000-word abstract by 
Apr. 30, 1991, to P.J. Layzell, Umist, PO Box 
88, Manchester, M60 1QD, UK, phone 44 
(61) 200-3338, fax 44 (61) 200-3364, e-mail 
p.layzell@uk.ac.umist(janet). 


Eurographics Workshop on Computer 
Graphics and Math.: Oct. 28-31, 1991, 
Genova, Italy. Sponsor: Inst, for Applied 
Math., Italian Nat’l Research Council. Submit 
three copies of extended abstract or full paper 
by Apr. 30, 1991, and final version by Dec. 

15,1991, to Bianca Falcidieno or Caterina Pi- 
enovi, Istituto per la Matematica Applicata, 
Via L.B. Alberti 4, 16132 Genova, Italy, 
phone 39 (10) 517-639, fax 39 (10) 517-801, 
e-mail falcidieno@image.ge.cnr.it or 
pienovi@image.ge.cnr.it. 


12th IEEE Symp. on Real-Time Sys- 
^7 terns: Dec. 3-6, 1991, San Antonio, 
Texas. Sponsor: IEEE Computer Soc. Techni¬ 
cal Committee on Real-Time Computing. Sub¬ 
mit five copies of paper by May 1, 1991, and 
extended abstract by Sept. 2, 1991, Lui Sha, 
Software Eng. Inst., Carnegie Mellon Univ., 
4500 Fifth Ave., Pittsburgh, PA 15213, phone 
(412) 268-5875, e-mail sha@sei.cmu.edu. 


Fourth Int’l Workshop on Petri Nets and 
Performance Models: Dec 3-5, 1991, Mel¬ 
bourne, Australia. Sponsor: Telecom Austra¬ 
lia. Submit five copies of full paper by May 1, 
1991, to Jonathan Billington, Telecom Austra¬ 
lia Research Labs, PO Box 249, Clayton, Vic., 


3168, Australia, phone 61 (3) 541-6416, fax 
61 (3) 544-2362, e-mailj.billington@trl.oz.au. 

11th Int’I Conf. of the Chilean Computer 
Science Soc.: Oct. 15-18, 1991, Santiago, 
Chile. Submit five copies of extended abstract 
by May 1,1991, and camera-ready version by 
Aug. 1,1991, to Udi Manber, Computer Sci¬ 
ence Dept., Univ. of Arizona, Tucson, AZ 
85721, fax (602) 621-4246, e-mail udi@cs. 
arizona.edu. 

Int’l Conf. on Microelectronics: Dec. 21-23, 
1991, Cairo. Submit paper by May 1, 1991, to 
M.I. Elmasry, VLSI Group, Univ. of Water¬ 
loo, Waterloo, Ont., Canada N2L 3G1, phone 
(519) 885-1211, ext. 3753, fax (519) 746- 
5195, e-mail elmasry@vlsi.uwaterloo.ca. 

J. of Parallel and Distributed Computing 

seeks articles for an upcoming special issue on 
intelligence processing computer systems. 
Submit six copies of manuscript by May 1, 
1991, to Jayantha Herath, Electrical and Com¬ 
puter Eng. Dept, Drexel Univ., Philadelphia, 
PA 19104, phone (215) 895-6758, fax (215) 
895-1695, e-mail jheraz@ocs.drexel.edu. 

ISCIS VI, Sixth Int’l Symp. on Com- 
puter and Information Sciences: Oct. 
30-Nov. 2, 1991, Ankara, Turkey. Sponsor: 
Bilkent Univ., IEEE Turkey Chapter. Submit 
four copies of full paper by May 1, 1991, to 
ISCIS VI, Bilkent Univ., Computer Eng. and 
Information Sciences Dept., Bilkent 06533 
Ankara, Turkey, phone 90 (4) 266-4133, fax 
90 (4) 266-4127. 

1991 IEEE Int’l Workshop on Defect and 
Fault Tolerance in VLSI Systems: Nov. 18- 
20, 1991, Hidden Valley, Pa. Submit 21 cop¬ 
ies of extended summary or full paper by May 
1, 1991, and final manuscript by Aug. 30, 

1991, to D.M.H. Walker, Electrical and Com¬ 
puter Eng. Dept., Carnegie Mellon Univ., 
Pittsburgh, PA 15213-3890, phone (412) 268- 
8522, fax (412) 268-2860, e-mail dmw@ece. 


KBSE 6, Sixth Knowledge-Based Software 
Eng. Conf.: Sept. 22-25, 1991, Syracuse, NY. 
Sponsors: Am. Assoc, for Artificial Intelli¬ 
gence et al. Submit six copies of full paper by 
May 1, 1991, to Peter G. Selfridge, AT&T 
Bell Labs, Rm. 3C-441, Murray Hill, NJ 
07974, phone (201) 582-6801, e-mail pgs@ 
research.att.com. 

Computer Science and Operations Re¬ 
search Conf.: Jan. 8-10, 1992, Williamsburg, 
Va. Sponsor: Operations Research Soc. of 
Am. Submit four copies of full paper by May 

1,1991, to Osman Balci, Computer Science 
Dept., Virginia Tech, Blacksburg, VA 24061- 
0106, phone (703) 231-4841, e-mail balci @ 
vtopus.cs.vt.edu. 

Conf. on Fuzzy and Neural Systems and 
Vehicle Applications: Nov. 8, 1991, Tokyo. 
Cosponsors: IEEE Industrial Electronics Soc., 
Japan Soc. for Fuzzy Theory and Systems. 
Submit abstract by May 1, 1991, to Ichiro 
Masaki, Computer Science Dept., General 
Motors Research Labs, 30500 Mound Rd., 
Warren, MI 48090-9055, phone (313) 986- 
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1466, fax (313) 986-9356, CSnet masaki@ 
gmr.com. 

Sixth Eurographics Workshop on Graphics 
Hardware: Sept. 1-2, 1991, Vienna. Submit 
four copies of extended abstract by May 3, 
1991, draft of paper by Aug. 9, 1991, and fi¬ 
nal version by Oct. 31,1991, to A. Kaufman, 
Computer Science Dept., State Univ. of New 
York, Stony Brook, NY 11794-4400, phone 
(516) 632-8441, fax (516) 632-8334, e-mail 
ari@sbcs.sunysb.edu; or M. Mehl, FhG-AGD, 
Wilhelminenstr. 7, D-6100 Darmstadt, Ger¬ 
many, phone 49 (6151) 155-153, fax 49 
(6151) 155-199, e-mail mehl@agd.fhg.de. 

1991 Int’l Display Research Conf.: Oct. 15- 
17, 1991, San Diego, Calif. Sponsor: Soc. for 
Information Display. Submit abstract by May 
3,1991, and camera-ready version by Aug. 

16, 1991, to Palisades Inst, for Research Ser¬ 
vices, Attn.: IDRC, 201 Varick St., Suite 
1140, New York, NY 10014, phone (212) 
620-3371, fax (212) 620-3379. 


Int’l Coni', on Parallel and Distribut- 
ed Information Systems: Dec. 4-6, 
1991, Miami Beach, Fla. Cosponsors: IEEE 
Computer Soc. et al. Submit seven copies of 
full paper by May 10,1991, and abstract by 
electronic mail to H.V. Jagadish, 3C414A, 
AT&T Bell Labs, 600 Mountain Ave., Murray 
Hill, NJ 07974, e-mailjag@research.att.com. 

® IEEE Micro seeks manuscripts for its 
December 1991 issue on database ma¬ 
chine implementation. The issue will be pub¬ 
lished in coordination with the December da¬ 
tabase issue of Computer. Submit six copies 
of each manuscript by May 15,1991, to M. 
Abdelguerfi, Computer Science Dept., Univ. 
of New Orleans, Lakefront, LA 70148, phone 
(504) 286-7076, Bitnet macs@uno. 


Fifth Int’l Symp. on Methodologies for In¬ 
telligent Systems: Oct. 16-19, 1991, Char¬ 
lotte, N.C. Sponsors: Univ. of North Carolina 
et al. Submit four copies of paper by May 15, 
1991, to Bill Chu, Computer Science Dept., 
Univ. of North Carolina, Charlotte, NC 28223, 
phone (704) 547-4568, e-mail billchu@ 
unccvax.uncc.edu. 


Seventh Computer Security Applications 
Conf.: Dec. 2-6, 1991, San Antonio, Texas. 
Submit five copies of paper by May 17,1991, 
and camera-ready copy by Sept. 18,1991, to 
Ann Marmor-Squires, TRW Systems Div, 
2752 Prosperity Ave., Fairfax, VA 22031, 
phone (703) 876-8161, e-mail marmor@ 
a.isi.edu. 

11th IEEE Symp. on Mass Storage 

Systems: Oct. 7-10, 1991, Monterey, 
Calif. Sponsor: IEEE Computer Soc. Techni¬ 
cal Committee on Mass Storage Systems and 
Tech. Submit final papers by May 30,1991, 
to Bernard T. O’Lear, NCAR, PO Box 3000, 
Boulder, CO 80307, phone (303) 497-1268, 
fax (303) 497-1137. 

Third Int’l Symp. on Parallel and 
N57 Distributed Processing: Dec. 1-5, 
1991, Dallas. Submit paper by May 31, 1991, 
to Behrooz Shirazi, Univ. of Texas at Arling¬ 
ton, Computer Science Eng. Dept., Box 
19015, Arlington, TX 76019-0015, phone 
(817) 273-3605, fax (817) 273-2548, e-mail 
shirazi@evax.utarl.edu. 


IEEE/ACM Int’l Conf. on Developing 
'vi-7 and Managing Expert System Pro¬ 
grams: Sept. 30-Oct. 2, 1991, Washington, 
DC. Submit five copies of complete paper by 
May 31, 1991, to Larry Medsker, Computer 
Science and Information Systems Dept., 
American Univ., Washington, DC 20016. 


^ IEEE Software plans a special issue on 
integrated computer-aided software en¬ 
gineering in March 1992. Submit seven copies 
of manuscript by May 15,1991, to Ronald J. 
Norman, Information and Decision Systems 
Dept., San Diego State Univ., San Diego, CA 
92182-0127, phone (619) 594-3734, fax (619) 
594-1573, e-mail rnorman@sciences.sdsu.edu. 


Third Int’I Workshop on Foundations of 
Models and Languages for Data and Ob¬ 
jects: Sept. 23-27, 1991, Aigen, Austria. Co¬ 
sponsors: Gesellschaft fur Informatik et al. 
Submit four copies of extended abstract by 
May 15,1991, and camera-ready version by 
Aug. 31,1991, to Gunter Saake, Informatik, 
Abt. Datenbanken, Technical Universitat, 
Postfach 3329, D-W3300 Braunschweig, Ger¬ 
many, phone 49 (531) 391-3267, fax 49 (531) 
391-4577, e-mail saake@infbs.uucp or saake 
@dbsinf6.bitnet. 


Fourth Artificial Intelligence Symp.: Sept. 
20-21, 1991, Fredericton, N.B., Canada. Spon¬ 
sor: Univ. of New Brunswick. Submit four 
copies of extended abstract or complete paper 
by May 15,1991, to Brad Nickerson, Com¬ 
puter Science Faculty, Univ. of New Bruns¬ 
wick, Fredericton, N.B., Canada E3B 5A3, 
phone (506) 453-4566, fax (506) 453-3566, 
e-mail bgn@unb.ca. 


IJCNN 91 Singapore, Int’l Conf. on Neural 
Networks: Nov. 18-21, 1991, Singapore. Co¬ 
sponsors: IEEE Neural Networks Council, 

Int’l Neural Networks Soc. Submit one origi¬ 
nal and seven copies of full paper by May 31, 
1991, to Nomi Feldman, Meeting Manage¬ 
ment, 5565 Oberlin Dr., Suite 110, San Diego, 
CA 92121, fax (619) 535-3880 (for US sub¬ 
mittals); Toshio Fukuda, IJCNN 91 Singapore, 
Mechanical Eng. Dept., Nagoya Univ., Furo- 
cho, Chikusa-ku, Nagoya 464-01, Japan, fax 
81 (52) 3781-9243 (submittals in Japan); or 
Teck-Seng Low, IJCNN 91 Singapore, Comm. 
Int’l Associates Pte. Ltd., 44/46 Tanjong Pa- 
gar Rd., Singapore 0208, phone (65) 226- 
2838, fax (65) 226-2877 (all other regions). 


,£j^, 25th Asilomar Conf. on Signals, Sys- 
terns, and Computers: Nov. 4-6, 1991, 
Pacific Grove, Calif. Sponsors: Naval Post¬ 
graduate School, San Jose State Univ. Submit 
three copies of 100-word abstract and exten¬ 
sive summary by June 1,1991, to Neil K. 
Jablon, AT&T Bell Labs, 200 Laurel Ave., 
Rm. 1G-540, Middletown, NJ 07748-4801 
phone (201) 957-2011. 

Fifth Int’l Conf. on VLSI Design: Jan. 
4-7, 1992, Bangalore, India. Sponsor: 
VLSI Soc. of India et al. Submit six copies of 
paper by June 1,1991, to Yashwant K. 


Malaiya, Computer Science Dept., Colorado 
State Univ., Fort Collins, CO 80523, phone 
(303) 491-7031; or K.S. Raghunathan, Micro¬ 
electronic and Computer Division, Indian 
Telephone Industries, Bangalore, 560016, In¬ 
dia, phone 91 (812) 563-211. 


Hawaii Int’l Conf. on Systems Scienc- 

es: Jan. 7-10, 1992, Koloa, Hawaii. Co¬ 
sponsors: IEEE, ACM. Submit six copies of 
paper by June 5,1991, to Luqi, Computer 
Science Dept, Naval Postgraduate School, 
Monterey, CA 93940, phone (408) 646-2468. 

© Eighth Int’l Conf. on Data Eng.: Feb. 

3-7, 1992, Phoenix, Ariz. Submit five 
copies of complete paper by June 7,1991, 
and camera-ready version by Oct. 31,1991, to 
Forouzan Golshani, Computer Science and 
Eng. Dept., Arizona State Univ., Tempe, AZ 
85287-5406, phone (602) 965-2855, e-mail 
golshani@asuvax.eas.asu.edu. 

Micro 24, 24th ACM/IEEE Int’l 
Symp. and Workshop on Microarchi¬ 
tecture: Nov. 18-20, 1991, Albuquerque, 
N.M. Submit four copies of manuscript by 
June 16,1991, and final version by Sept. 17, 
1991, to (by geographical region) Andrew 
Wolfe, Electrical and Computer Science 
Dept., Carnegie Mellon Univ., Pittsburgh, PA 
15213-3890, phone (412) 268-7102, fax (412) 
268-2860, e-mail wolfe@ece.cmu.edu; Toshio 
Nakatani, IBM Japan, 5-19, Sanbancho, 
Chiyoda-ku, Tokyo 102, Japan, phone 81 (03) 
288-8409, fax 81 (03) 265-4251, e-mail 
nakatani @jpntscvm.bitnet; or Hans Mulder. 
Electrical Eng. Dept., Delft Univ. of Tech. PO 
Box 5031, 2600 GA Delft, the Netherlands, 
phone 31 (0) 1578-5021, fax 31 (0) 1578- 
4898, e-mail hansm@duteca.et.tudelft.nl. 

IEEE Infocom 92,11th Conf. on 
'vAy Computer Comm.: May 4-8, 1992, 
Florence, Italy. Cosponsor: IEEE Comm. Soc. 
Submit six copies of paper by June 30,1991, to 
L. Fratta, Politecnico di Milano, c/o Cefriel, Via 
Emanueli, 15,20126 Milano, Italy, phone 39 (2) 
2399-3578, fax 39 (2) 2399-3587, e-mail 
fratta @imicefr.bitnet; or J. Kurose, Computer 
and Information Science Dept., Univ. of Massa¬ 
chusetts, Amherst, MA 01003, phone (413) 545- 
1585, e-mail kurose@cs. umass.edu. 


ZSX IEEE Trans. Computers plans a spe- 

cial issue on fault-tolerant computing in 
May 1992. Submit seven copies of manuscript 
by July 1,1991, to W. Kent Fuchs, 1101 W. 
Springfield Ave., Coordinated Science Lab, 
Univ. of Illinois, Urbana, IL 61801, phone 
(217)333-9731. 

ICSE 92,14th Int’l Conf. on Software 

Eng.: May 11-15,1992, Melbourne, 
Australia. Cosponsors: IEEE Computer Soc. et 
al. Submit six copies of full paper or experi¬ 
ence report by Sept. 6,1991, to A.Y. Mont¬ 
gomery, Computer Science Dept., Royal Mel¬ 
bourne Inst, of Tech., PO Box 2476V, Mel¬ 
bourne 3001, Victoria, Australia, phone 61 (3) 
660-2943, fax 61 (3) 662-1617, e-mail aym@ 
goanna.cs.rmit.oz.au. 
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Call For Papers 

IEEE INTERNATIONAL CONFERENCE 
on WAFER SCALE INTEGRATION-1992 

Fairmont Hotel 

San Francisco, California U.S.A. 

January 22-24, 1992 


Sponsored by the IEEE Computer Society 
and the IEEE Components, Hybrids, and Manufacturing Technology Society 

General Chair : Vijay K. Jain University of South Florida 
Program Chair : Peter W. Wyatt MIT Lincoln Laboratory 


The IEEE International Conference on Wafer Scale Integration is the premier forum for 
reporting new WSI devices and progress in WSI Design, Fabrication, and Packaging 
technologies. Papers directly related to WSI are sought from workers around the 
world. Preference will be given to papers that describe working WSI devices and 
systems. Exhibition of operating hardware at the conference is also strongly 
encouraged. Submissions are invited in the following areas: 


• System Applications of WSI 

• WSI Implementations 

• WSI Architectures 

• WSI Devices 

• WSI Packaging (Incl. Thermal Design) 

• I/O Approaches (Electrical/Optical) 


• Clock, Signal, and Power Distribution 

• Testing and Testability 

• Defect Tolerance/Yield Enhancement 

• Fault Tolerance/Self Repair 
•CAD for WSI 

• Silicon on Silicon Hybrids 


Six copies of paper summaries (3 to 4 pages, plus figures) including the name, phone 
number, and mailing address of the preferred contact are due by June 15, 1991. The 
authors of accepted papers will provide camera-ready full text by October 1, 1991 for 
publication in a book that will be distributed at the conference. Oral presentations will 
be 20-25 minutes in length. The summary should be sent to: 


American Submissions 
Dr. Peter W. Wyatt 
MIT Lincoln Laboratory, B-153 
Box 73 

Lexington, MA 02173-9108 
Phone (617) 981-7232 


European Submissions 

Professor R. Mike Lea 
Brunei University 
Uxbridge UB8 3PH 
UNITED KINGDOM 


Asian Submissions 

Dr. Tadashi Sasaki 
Sharp Corporation 
8, Ichigaya, Hachiman-cho 
Shinjuku-ku, Tokyo 162 
JAPAN 


IEEE COMPUTER SOCIETY 


THE INSTITUTE OF ELECTRICAL 
AND ELECTRONICS ENGINEERS. INC 




CAREER OPPORTUNITIES 


RATES: $12.00 per line, (ten lines mini¬ 
mum). Average five typeset words per 
line, eight lines per column inch. Add 
$10 for box number. Send copy at least 
one month prior to publication date to: 
Marian B. Tibayan, Classified Adver¬ 
tising, COMPUTER Magazine, 10662 
Los Vaqueros Circle, PO Box 3014, 
Los Alamitos, CA 90720-1264; (714) 
821-8380; fax (714) 821-4010. 

In order to conform to the Age Discrimina¬ 
tion in Employment Act and to discourage 
age discrimination, COMPUTER may re¬ 
ject any advertisement containing any of 
these phrases or similar ones: "...recent 
college grads...," "...1-4 years maximum 
experience...," "...up to 5 years experi¬ 
ence," or "...10 years maximum 
experience." COMPUTER reserves the 
right to append to any advertisement, with¬ 
out specific notice to the advertiser, 
"Experience ranges are suggested mini¬ 
mum requirements, not maximums." 
COMPUTER assumes that, since advertis¬ 
ers have been notified of this policy in 
advance, they agree that any experience re¬ 
quirements, whether stated as ranges or 
otherwise, will be construed by the reader 
as minimum requirements only. 


THE OHIO STATE UNIVERSITY 
Dean of The College of Engineering 

The Ohio State University invites applica¬ 
tions and nominations for the position of 
Dean of the College of Engineering. 

The Dean will lead a distinguished 260- 
person faculty, serving4,500 undergraduate 
and 1,400 graduate students in 16 academic 
units. The Dean will administer a total budget 
of $90,000,000, including the sixth largest 
engineering college research budget in the 
United States, and will have the support of 
30,500 College of Engineering alumni. The 
candidate should be a recognized leader in 
administration, research and teaching. The 
Dean will be a key member of the university 
leadership and will be expected to contribute 
to the broad academic and cultural missions 
of the entire university. 

The position will be available July 1, 
1991. The Ohio State University is an equal 
opportunity/affirmative action employer, 
and the candidate must be committed to 
these principles. The Search Committee will 
accept and review applications until the posi¬ 
tion is filled. 

Send applications and nominations, in¬ 
cluding curriculum vitae and the names of 
three references to Professor Leon Peters, 
Jr., Chair, Search Committee for the Dean 
of the College of Engineering, Department 
of Electrical Engineering, The Ohio State 
University. 2015 Neil Avenue, Columbus, 
OH 43210. 


ACADEMIA SINICA 
Taiwan, Republic of China 
Institute of Information Science 

Applications are invited for research posi¬ 
tion in Institute of Information Science, 
Academia Sinica. Ph D. in Computer Sci¬ 
ence or closely related fields required. 
Demonstratable research ability necessary. 
Applicants for senior positions must have 
proven research record. All fields in Com¬ 
puter Science are welcome. 

The Institute offers a good research en¬ 
vironment, No duty of teaching. Facilities in¬ 
clude a 32-node NCUBE 2 parallel super¬ 
computer. many SUN, SGI. and E&S work¬ 
stations. An easily accessible ETA-10Q 
supercomputer is in the Academia Sinica. 

Interested people please send application 
to Dr. Y.S. Kuo, Acting Director, Institute of 
Information Science, Academia Sinica, Tai¬ 
pei, Taiwan, 11529, Republic of China. 
Fax: (001-886-2) 782-4814. 


WRIGHT STATE UNIVERSITY 

Department of Computer Science 
and Engineering 

Applicants are invited for tenure-track and 
visiting faculty positions at all ranks. The suc¬ 
cessful candidate must have a Ph.D. in com¬ 
puter science, computer engineering, or 
equivalent background and have demon¬ 
strated forward looking and creative re¬ 
search. Further desired attributes include: 
capability to direct Ph.D. candidates in com¬ 
puter science or computer engineering and 
the ability to acquire funds and/or direct 
research projects. Preferred technical areas 
are distributed systems, networking, and 
database, but other areas will be considered. 
Rank and competitive salaries are determined 
by qualifications and experience. 

The university is located in a high technol¬ 
ogy environment among industrial/military 
research and development facilities, includ¬ 
ing Wright Patterson Air Force Base and 
NCR. Department strengths include a fully 
networked Unix environment of Sun & DEC 
workstations: Cray access; graduate labora¬ 
tories in AI, optical computing, neural net¬ 
works, and robotics; established research 
programs; industrial/military support; 
degree programs in both computer science 
and computer engineering; and a large 
graduate student population. 

Please submit a detailed resume including 
names of three references to: CSNET ad¬ 
dress - amcaulay@cs.wright.edu or Alastair 
D. McAulay, NCR Distinguished Professor 
and Chair, Department of Computer Sci¬ 
ence and Engineering, Wright State Univer¬ 
sity, Dayton. Ohio 45435. Pending avail¬ 
ability of funding, reviewing for positions 
will begin February 15, 1991 and continue 
monthly until positions are filled or until 
September 1, 1991. 

An Equal Opportunity/Affirmative Action 
Employer. 


NATIONAL CHENG RUNG 
UNIVERSITY 
Tainan, Taiwan 

The Institute of Information Engineering at 
the National Cheng Kung University is ex¬ 
panding and is looking to fill faculty positions 
in the following areas: databases, software 
engineering, computer engineering, net¬ 
work management, and MIS. Candidates 
should send a curriculum vitae and the 
names of three references to Dr. Jhing-Fa 
Wang. Director. Institute of Information 
Engineering. National Cheng Kung Univer¬ 
sity. Tainan. Taiwan 70101. E-Mail: 
NCKUT115@TWNMOE10.BITNET. 


UNIVERSITY OF MIAMI 
Department of Mathematics and 
Computer Science 

Several tenure track faculty appointments 
in the Department of Mathematics and Com¬ 
puter Science may become available in 
August, 1991. subject to budgetary con¬ 
sideration. Candidates must have a Ph.D. or 
equivalent degree and excellent research 
potential and accomplishments, commensu¬ 
rate with the level of the position, and a 
strong commitment to teaching and research. 
Salaries will be competitive. Applicants 
should send a vita and three letters of refer- 

Alan C. Zame. Chairman 
Department of Mathematics and 
Computer Science 
University of Miami 
P O . Box 249085 
Coral Gables. Florida 33124 
The University of Miami is an Equal Op¬ 
portunity/Affirmative Action Employer. 


TECHNICAL UNIVERSITY OF 
DARMSTADT IN GERMANY 
Faculty Position in 
Computer Engineering 

The Technical University of Darmstadt in 
Germany invites applications and nomina¬ 
tions for the position of Professor (C4) in 
Computer Systems (Rechnersysteme Nach- 
folge Piloty Kenn-Nr.:28). Candidates for 
the position should have a well established 
reputation in research and experience in one 
or more of the following areas: computer ar¬ 
chitecture. computer organization, logic 
design of circuits and systems, multiproces¬ 
sor systems, real time systems, distributed 
computing and networking, fault tolerant 
computers, systems for signal processing, 
pattern recognition etc. 

Candidates are invited to submit their ap¬ 
plication including a curriculum vitae, a list of 
publications and a description of their research 
activities to the president of THD. Karolinen- 
platz 5. D-6100 Darmstadt. Germany. 
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THE UNIVERSITY OF 
MISSOURI-ROLLA 

The Department of Computer Science at 
the University of Missouri-Rolla is seeking 
qualified applicants for tenure-track faculty 
positions. Applicants must have a strong in¬ 
terest in theoretical Computer Science. Re¬ 
search experience in theoretical aspects of 
Distributed and Parallel Software Engineer¬ 
ing is a strong plus. Applicants for junior 
positions must demonstrate evidence of their 
ability to perform research and have had 
prior involvement in group research ac¬ 
tivities. Applicants for senior positions must 
have a demonstrated record of research and 
funding emphasizing research team leader¬ 
ship as the principal investigator. Course 
load for the first two years is normally one 
course per semester. 

The Department grants the B.S., M.S. 
and PhID. degrees. The Ph.D. program has 
been active since 1977 and the Department 
currently has 75 graduate students. Depart¬ 
mental funded research is growing with year¬ 
ly funding above half a million dollars. Major 
computing facilities include an Intel iPSC/2 
16 processor multicomputer, VAXes, and 
HP equipment in the Departmental Experi¬ 
mental Computation Laboratory, and high- 
function Unix-based workstations for faculty 
and students. Interdisciplinary research ac¬ 
tivities exist in the UMR Intelligent Systems 
Center and faculty members in the Depart¬ 
ment may become Research investigators in 
this Center. 

The University of Missouri-Rolla is the pri¬ 
mary science and engineering campus of the 
University of Missouri system, currently has 
an enrollment of 5000 students, and is situ¬ 
ated in a non-urban environment in the 
Ozarks. St. Louis is IV2 hours away via inter¬ 
state highway. Salary is competitive with 
Big-10/Big-8 universities. 

Applicants should send a vita plus the 
names of three references and a statement of 
research and teaching interests to: 

Faculty Search Committee 
Department of Computer Science 
University of Missouri-Rolla 
Rolla. MO 65401 
(314) 341-4491 
(csdept@cs. umr.edu) 

An equal opportunity institution. 


UNIVERSITE CATHOLIQUE 
DE LOUVAIN 
Belgium 
Department of 

Computing Science and Engineering 

The Uniuersite Catholique de Louuctirt in¬ 
vites applications for a tenure-track faculty 
position in the Department of Computing 
Science and Engineering to be filled by 
October 1. 1991. Rank and salary depend 
upon qualifications and experience. Re¬ 
sponsibilities include research, supervision of 
graduate student research, participation in 
the management of research projects, grad¬ 
uate and undergraduate teaching in various 
study programs. Candidates should have a 
Ph.D. in computing science and/or engi¬ 
neering and a commitment to excellence in 
both research and teaching: leadership skills 


are highly valued. A working knowledge of 
the French language is expected. 

Preference will be given to candidates with 
experience in one or several of the following 
areas: programming methods and theories, 
design and logic of data and knowledge 
bases, information systems. 

The department belongs to the School of 
Engineering: it is located in the new city of 
Louvain-la-Neuve. 30 km. south of Brus¬ 
sels. the capital of Belgium, in the heart of 

Additional information about the position 
may be obtained from Prof. E. Milgrom. 
President du Department GIMA. Place 
Sainte-Barbe. 2. B-1348Lo,uvain-la-Neuve. 
Belgium (Tel: +32 10 47 31 50. Fax: +32 
10 45 03 45. E-mail: em@info.ucl.ac.be). 

A resume (including full bibliography), a 
certified copy of the degree, one copy of the 
five most significant publications, a research, 
plan for the next three years and the names 
of three references should be sent before 
April 15, 1991 to: Prof. P. Macq. Recteur 
UCL. Place de I'Universite. 1. B-1348 
Louvain-la-Neuve. Belgium. 


RESEARCH ENGINEER 

Research and develop heterogeneous 
computer screen sharing and networking 
systems which include the translation of dif¬ 
ferent windowing systems on various operat¬ 
ing systems and networks (such as Mac Win¬ 
dow. MS-Windows. X Window. Mac OS. 
DOS. UNIX. AppleTalk. NetWare and 
TCP/IP). Must have MS in ECE or EE. Also: 
Background in R&D of windowing systems 
and computer networks. Knowledge of: Mac 
OS. DOS. UNIX. MS-window. X Window. 
Appletalk. TCP/IP. ISO OS1 structure, and 
accoustic computer accessories. Program¬ 
ming languages: Pascal: C or Object-C: 
PostScript. Full-time (40 hrs/week). 
$34.343.00/year. Must have proof of legal 
authority to work in U.S. The job order 
number for this job opportunity is KS 
1901908. Please apply at: 

Lawrence Department of Human Re¬ 
source Office 
833 Ohio Street 
Lawrence. Kansas 66044 
Telephone Number (913) 843-0531 
or refer to job order number when submit¬ 
ting a resume to the above referenced office. 


UNIVERSITY OF MINNESOTA, 
MORRIS 

The Division of Science and Mathematics 
of the University of Minnesota. Morris seeks 
individuals to teach upper and lower division 
.computer science courses. Temporary and 
tenure track positions are expected to be 
available. A Ph.D. or ABD in Computer Sci¬ 
ence or closely related area and research are 
required for tenure track position, an M.S. in 
Computer Science is required for the tem¬ 
porary positions. Appointments will be at the 
Assistant Professor level for those with 
a Ph D. Teaching load is 8-10 hrs. per 
quarter. Starting date is Sept. 16. 1991. 
Salary negotiable. 


UMM is a liberal arts college with 2000 stu¬ 
dents and 110 faculty. It is located 150 miles 
west of the Twin Cities. Equipment includes 
DEC VAXes, workstations. Apple Mac¬ 
intoshes and PC-compatible systems. All 
equipment is networked together. 

Send resume, transcript and three letters 
of reference, by April 22. 1991. to: Dr. 
James Olson. Chairman Division of Science 
and Mathematics. Room 217. University of 
Minnesota. Morris. MN 56267. Please in¬ 
dicate whether applying for tenure track or 
temporary position. Send inquiries to andy 
@caa. mrs.umn.edu. 

The University of Minnesota. Morris is an 
equal opportunity educator and employer 
and specifically invites and encourages ap¬ 
plications from women and minorities. 


UNIVERSITY OF CALIFORNIA, 
LOS ANGELES 

Department of Computer Science 

Applications are invited for a tenure-track 
position in the UCLA Computer Science De¬ 
partment. Both junior an.d senior level ap¬ 
plicants are solicited. A doctoral degree is 
required along with a demonstrated commit¬ 
ment to teaching and outstanding research. 
We are especially interested in candidates 
whose research is in the area of computer 
systems (hardware and software). Please 
send a resume, a subset of your best papers, 
and the names of four references to: 
Professor Wesley Chu, Chair 
Computer Science Department 
(Recruiting) 

3731 D Boelter Hall 
University of California 
Los Angeles. CA 90024 
The University of California is an Equal 
Opportunity. Affirmative Action Employer. 


THE UNIVERSITY OF TEXAS 
AT ARLINGTON 

The Department of Computer Science 
Engineering at The University of Texas at 
Arlington invites applications for tenure- 
track or visiting faculty positions in all areas of 
computer science or computer engineering. 
Applicants with expertise relating to reliable 
real-time distributed systems, telecommuni¬ 
cations software, object-oriented systems, 
scientific visualization, knowledge-based sys¬ 
tems. or parallel processing will be given 
preference. Rank is open. An earned doc¬ 
torate or equivalent and a commitment to 
teaching and scholarly research are re¬ 
quired. Openings are expected for Septem¬ 
ber 1991. Applications will be accepted until 
all positions are filled. Interested persons 
should send a resume and a list of references 
to Bill D. Carroll. Professor and Chairper¬ 
son. Computer Science Engineering Depart¬ 
ment. P.O. Box 19015. The University of 
Texas at Arlington. Arlington. TX 76019. 
Phone: 817-273-3787. FAX: 817-273- 
2548. Inter-net carroll@evax.uta.edu. 

The University of Texas at Arlington is an 
Equal Opportunity Affirmative Action 
Employer. 
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CARNEGIE MELLON UNIVERSITY 
School of Computer Science 

The Introductory Programming Group 
within the School of Computer Science has 
more than one non-tenure track, full-time 
teaching position available July 1991. The 
main duty is the teaching of undergraduate 
programming courses. Our computing facili¬ 
ties include 50 Macintosh computers, several 
servers, printers, and a LAN. Most courses 
use Pascal as a support language. 

Applicants for the positions must have a 
M.S. in Computer Science (or related field), 
and strong academic credentials or practical 
experience. Knowledge of Pascal and Mac¬ 
intosh is preferred. Qualified applicants 
should send a letter of application, resume, 
and three letters of recommendation to: 
Jacobo Carrasquel, Carnegie Mellon, School 
of Computer Science, Pittsburgh, PA, 15213. 

Carnegie Mellon is an Equal Opportunity/ 
Affirmative Action Employer. Women and 
minorities are especially encouraged to apply. 


ASSOCIATE ENGINEER 

Associate Engineer needed to design, 
develop, and analyze embedded systems 
with custom firmware for Boulder, CO com¬ 
pany that manufactures 8mm tape drives 
used for secondary data storage devices by 
original equipment manufacturers (OEMs), 
system integrators, and value added resellers 
(VARs). Custom design firmware to meet 
specific OEM applications. Interface with 
product test and technical support to ensure 
best product performance. Requires M.S. in 
Electrical Engineering, including courses in 
microprocessors and control systems: work¬ 
ing knowledge of. and willingness to work 
almost exclusively with, Motorola & Intel 
microprocessors and their assembly lan¬ 
guages: working knowledge of C language 
compilers, assemblers and software library 
techniques: working knowledge of SCSI 1 & 
II (knowledge may be gained in employment 
or in educational program). $35.900/year: 
8:00 a m.-5:00 p.m.. M-F. Respond by 
resume to Colorado Department of Labor & 
Employment. Division of Employment & 
Training. 600 Grant. Suite 900. Denver. CO 
80203. ATT: James Shimada. and refer to 
Job Order No. C03195354. 


UNIVERSITY OF NEVADA, 

LAS VEGAS 

Department of Computer Science 

DEPARTMENT CHAIR: The Howard R. 
Hughes College of Engineering at the Uni¬ 
versity of Nevada. Las Vegas seeks appli¬ 
cants for the position of Chair of the Depart¬ 
ment of Computer Science. The Chair will 
be expected to develop new funded research 
programs, help in the launching of a Ph D. 
program anticipated to start in the fall of 
1991. and to have teaching duties. Appli¬ 
cants must have a Ph.D. in Computer Sci¬ 
ence or a closely related field. The applicant 
must have experience in the advising of doc¬ 
toral students and a record of distinction in 


teaching, research, and service. Previous 
administrative experience at the Department 
or College level preferred. 

UNLV is rapidly expanding and develop¬ 
ing. Its engineering and computer science 
programs have a solid research base and a 
new $15 million engineering complex. The 
Department of Computer Science has ten 
faculty and an enrollment approximately 
350 undergraduate and 35 graduate stu¬ 
dents. Current faculty research interests in¬ 
clude: artificial intelligence, software engi¬ 
neering. operating systems, programming 
languages, database management, parallel 
algorithms, computer graphics and com¬ 
puter simulation. The faculty are heavily 
involved in externally funded research 

The Department has modern, well 
equipped laboratory facilities including: Sun 
SPARCstations. NeXT workstations. Silicon 
Graphics 4 D's. a Symbolics LISP machine. 
DEC workstation, and Intel Hypercube, and 
an Ethernet local area network. In addition, 
the faculty have access to a CRAY Y-MP in 
the National Supercomputing Center for 
Energy and the Environment operated by 
the College. 

The appointment will begin Fall 1991. Ap¬ 
plicants must submit a letter of application, a 
vitae and the names of three references with 
telephone numbers. Review of applications 
will begin March 15. 1991 and continue until 
position is filled. Send applications to:Dr. 
William R. Wells. Dean. Howard R. Hughes 
College of Engineering. University of 
Nevada. Las Vegas. 4505 Maryland Park¬ 
way. Las Vegas. NV 89154. 

The University of Nevada. Las Vegas is an 
Equal Opportunity Affirmative Action Em¬ 
ployer and encourages women and minori¬ 
ties to apply. UNLV employs only U S. 
citizens and aliens authorized to work in the 

US, 


SYSTEM SOFTWARE ENGINEER, 
Applications Division, 
Applications Strategy Group 

By 5/1/91. please send resume to: 
Employment Security Department 
ES Division. Attn: Job “247616 
Olympia. Washington 98504 
JOB DESCRIPTION: 

Designs, implements and tests complex 
and high level systems and software for mi¬ 
crocomputers. Assumes lead responsibility 
and directs others to design and implement 
Windows Hypertext Help systems software, 
including graphics display layout, help com¬ 
piler. and modifications to Help system for 
multiplatform operation, utilizing "C" and 86 
Assembler Series languages, and MS-DOS 
operating system. Assumes major project re¬ 
sponsibility including: 1) requirements and 
analysis of project specifications: 2) product 
design: and 3) implementation schedules. 
JOB REQUIREMENTS: 

Bachelors degree in electrical engineering, 
computer science, mathematics or physics. 
Two years of work experience in directing 
others to design and implement Hypertext 
Help system, graphics display layout, trans¬ 
lator. and windowing software and in modi- 


including six months work experience in pro¬ 
gramming or computer software design utili¬ 
zing "C" and 86 Assembler Series languages 
and MS-DOS operating system. 

Must have legal authority to work in the 
United States. 

Job location: Redmond. Washington. 

Salary: $40,500-47.000 per annum, de¬ 
pending on experience. 

40 hours per week, flex time. 

EOE. 


GEORGIA INSTITUTE 
OF TECHNOLOGY 

The College of Computing at Georgia 
Tech invites applications for a faculty posi¬ 
tion at the level of Assistant Professor in the 
area of Artificial Intelligence. The ideal can¬ 
didate would have a Ph D in Computer Sci 
erice. with a published record of solid re¬ 
search accomplishments, and an interest in 
interdisciplinary research on knowledge 
based problem solving and knowledge 
based systems. 

Since we would like to fill this position as 
soon as possible, candidates should send 
complete resumes and names of at least 
three references by April 30. 1991. The ap¬ 
plications should be sent to Professor Pete 
Jensen. Associate Dean. College of Compu¬ 
ting. Georgia Institute of Technology. Atlan 
ta. Georgia 30332-0280: Phone: (404) 
894-3186: e-mail: pete@cc.gatech.edu: 
FAX: (404) 853-9378. 

Georgia Tech is an equal opportunity 
employer. 


SOFTWARE DEVELOPMENT 
ENGINEER 

Software Development Engineer needed 
to design and develop software in the area of 
operator services on a digital telecommuni 
cation switch. Design, document, imple¬ 
ment and test software features requested by 
customers. Debug and resolve software re¬ 
lated problems reported by customers or sys 
tern test. Assist other engineers in their 
software development including document 
reviews and code inspections. Interact with 
management on technical and administra 
five issues. Solve technical problems that af¬ 
fect the performance of the digital switch in 
regards to feature functionality in the area of 
call processing. Requires a Bachelor's de 
gree in Computer Science''Electrical Engi¬ 
neering or its' equivalent and two years ex 
perience in job offered, or will consider the 
completion of all course requirements for a 
Master's degree in Computer Science 'Elec 
trical Engineering, in lieu of Bachelor and 
two years. Background must include at least 
six months experience or education in high 
computer languages: telephony and compu 
ter network. 40 hour work week. $38,000 
per year. Apply at the Texas Employment 
Commission. Dallas. Texas, or send resume 
to the Texas Employment Commission. 
Austin. Texas. TEC Building. Austin. Texas. 
78778. Job Order “6342634. Ad Paid By 
An Equal Employment Opportunity Employer. 


COMPUTER 













DESIGN & DEVELOPMENT 
ENGINEER 

(Computer Applications) 

Master’s Degree in Electrical Engineering 
and 4 years experience in the job offered or 
related occupation of Research & Design 
Engineer (systems). Write software pro¬ 
grams for hydrologic instrumentation proj¬ 
ects for MC68HC11 and MC68000 micro¬ 
processors using high level computer lan¬ 
guage including Assembly, BASIC, Fortran, 
Pascal and C in order to perform digital sig¬ 
nal processing tasks. Develop test equip¬ 
ment and procedures. Develop data man¬ 
agement programs for water resource man¬ 
agement and subsurface fluid flow. 40 hr. 
wk.; Salary $30,000/year. Application by 
resume to Wyoming Department of Labor & 
Employment, Laramie Job Service Center, 
112 South Fifth Street, Laramie, Wyoming 
82070. Refer to Order NO. WY0290663. 


SYSTEMS ENGINEER 

Central Ohio Computer & Data Process¬ 
ing Consultant firm seeking systems engi¬ 
neer to design, develop, test and administer 
voice information system, a telecommunica¬ 
tions product that combines a local area net¬ 
work and audio response unit, host commu¬ 
nication. and transcription facilities, accessed 
by telephone network. The system provides 
ability to distribute information on a local 
area network, provide for an alarm system, 
compiles management reports and data, and 
monitors facilities. System will interact 
on local area network, using Ethernet-type 
protocol and implemented by the TCP-IP 
Networking standard. Requires M.S. in 
Computer Science and knowledge of net¬ 
work systems. UNIX (tm) operating system, 
interactive systems and data structures as 
demonstrated by not less than six (6) credit 
hours of research or courtework in each area 
of expertise. No experience required in 
above duties but applicants will qualify with 
one year experience in design and develop¬ 
ment of interactive software in UNIX (tm) 
and C. Will accept experience before or after 
degree. 40 hours a week, 8:00-5:00, Mon - 
Fri., $37,000/yr. Must have proof of legal 
authority to work permanently in U.S. Send 
resume in duplicate (no calls) to J. Davies, 
JO *1260255, Ohio Bureau of Employment 
Services, P.O. Box 1618, Columbus, OH 
43216. 


SYSTEM SOFTWARE ENGINEER 

Analyze automation requirements to 
determine electronic data processing system 
to provide system capabilities required. Inter¬ 
face with senior corporate and computer 
management to evaluate client's MIS system 
and participate in long range systems devel¬ 
opment and planning. Coordinate project 
and provide high level technical assistance to 
clients. Duties include: developing plans and 
schedules, preparing functional and techni¬ 
cal specifications: code inhouse programs 
and install and customize software packages; 
perform system testing and parallel run; 
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troubleshoot and monitor project progress. 
Duties performed using IBM 30XX/43XX, 
MVS. DOS, CICS, COBOL, DB2/SQL/ 
QMF, IMS/DB, TELON, SAS, Model 204, 
PL/1, SUN, DEC, VAX, UNIX, APS, 
dBASE III +, TSO/ISPF. Require Masters 
degree in MIS and 2 years experience as pro- 
grammer/analysi using systems/programs 
listed. $34,000/yr. Apply at Texas Employ¬ 
ment Commission, Dallas, Texas, or send 
resume to Texas Employment Commission, 
TEC Building, Austin, Texas 78778, J.O. 
*6344341. Ad paid by equal opportunity 
employer. 


OREGON STATE UNIVERSITY 

Department of Computer Science 

The Department of Computer Science in¬ 
vites applicants for tenure-track positions for 
Assistant, Associate, and Full Professor¬ 
ships. Specialization in computer graphics or 
software engineering is desirable, but all 
qualified applicants will be considered. Ap¬ 
plicants should have completed or expect to 
complete all requirements for a Ph.D. in 
computer science or a closely related field 
and should have demonstrated research and 
teaching potential. Candidates for senior 
positions should have established research 
reputations. Review of applications will begin 
November 1, 1990, and will continue until 
the positions are filled. Please send vita, 
statement of research interests and plans, 
and three letters of reference to: Walter G. 
Rudd, Chairman, Department of Computer 
Science, Oregon State University, Corvallis, 
OR 97331. 

Oregon State University is an equal op¬ 
portunity affirmative action employer and 
complies with Section 504 of the Rehabilita¬ 
tion Act of 1973. OSU has a policy of being 
responsive to the needs of dual-career 
couples. 


PROGRAMMER ANALYST / SOFTWARE 
DEVELOPMENT SPECIALIST 

Seattle: Responsible for research, devel¬ 
opment and maintenance of nationally and 
internally marketed actuarial software. 
Duties include the construction of client data¬ 
base, interfacing with client computer sys¬ 
tems, interacting with actuaries in software 
design and consulting engagements, quality 
assurance testing and technical documenta¬ 
tion. Duties entail work with IBM PC and 
PS/2 family of computers using PC-DOS 
operating system. Bachelor’s in Computer 
Science, one year experience on the job or 
one year experience as an Actuarial Pro¬ 
grammer. One year experience must include 
experience in programming in APL, C and 
Assembler; with IBM PC and PS/2 family of 
computers; and PC-DOS operating system. 
40 hrs./wk. $29,500/yr. Must have proof 
of legal authority to work permanently in the 
U.S. Send resume by May 1, 1991 to: Em¬ 
ployment Security Department, ES Division, 
Attn: Job *240074, Olympia, WA 98504. 


NEW 

RELEASE 

FROM 

IEEE COMPUTER 
SOCIETY PRESS 


The Test Access 
Port And 
Boundary-Scan 
Architecture 

by Colin Maunder and 
Rodham Tulloss 


This tutorial discusses approaches 
to design-for-testability between 
computers and companies and 
explains its connection to IEEE 
Standard 1149.1. It begins by 
describing the circumstances that 
led to the development of the 
standard, introduces boundary-scan 
techniques, and provides solutions 
to problems faced by this technology. 
Other key topics include: the 
structure of a typical board test 
program, testing and diagnosis of 
test logic, testing of boards, silicon 
implementation and related costs, 
interfacing to scan design, and 
applications to system debugging 
and emulation. 

399 pages. September 1990. Hardbound. 

Illustrations. ISBN 0-8186-9070-4. 

Catalog No. 2070 

List $55.00 Member $44.00 


To order your copy call 
1-800-CS-BOOKS 

or in CA call 
714-821-8380 

or FAX 

714-821-4010 




















BOOK REVIEWS 


Computer Graphics Handbook: Geometry and Mathematics 

Michael E. Mortenson (Industrial Press, New York, 1990, 254 pp., $24.95) 


Neither a textbook nor a comprehen¬ 
sive manual. Computer Graphics Hand¬ 
book is rather an attractive study guide 
and a quick reference guide. Many stu¬ 
dents will use it to supplement their text¬ 
books, and many programmers will keep 
it on their desks, overlapping their key¬ 
boards, an arm’s reach closer than heavi¬ 
er references. 

This book contains no original material. 
Its usefulness arises from an original pre¬ 
sentation and grouping of useful topics. 

Mortenson focuses on the problem of 
describing and mathematically manipu¬ 
lating shapes. Readers who wish to trans¬ 
late the mathematics into computer pro¬ 
grams are on their own. With only a few 
exceptions, the book contains no 
pseudocode or suggested data structures. 
Nor does the author describe the con¬ 
cepts, functionality, or syntax of standard 
computer graphics software libraries. In¬ 
stead, Mortenson offers an easy-to- 
browse guide to the geometry and alge¬ 
bra that’s most relevant to computer 
graphics programming. 

Each page illustrates one concept, and 
the table of contents lists each page’s 
topic. Mortenson grouped the topics into 
14 chapters. The top of each page fea¬ 
tures the chapter title in boldface print 
and the page topic in a box. 

Mortenson ordered the material in a 
reasonably sequential fashion so that 
vector concepts introduced on the first 
pages appear again in discussions of 
curves, surfaces, and affine transforma¬ 
tions on later pages. However, he made 
each page as self-contained as possible. 
Even beginning students who possess 
limited mathematical self-confidence 
will be able to jump around from page to 
page. Students who do jump to a middle 
page and get stuck on a reference to an 
unfamiliar concept will be able to unstick 
themselves by checking the index. 


Margin notes on each page typically 
annotate diagrams or describe how a 
concept applies in a more general case, 
and footnotes explain mathematical his¬ 
tory. Quotations from people in litera¬ 
ture, science, and mathematics embellish 
many pages. Generous white space on 
each page leaves room for the reader’s 
own notes. 

Computer Graphics Handbook gives 
roughly equal coverage to five main top¬ 
ics. The first is a standard review of vec¬ 
tor and matrix algebra. A discussion of 
classical geometry follows, including 
trigonometric functions, shapes de¬ 
scribed by polynomials of degree 2, and 
polyhedra. Next, a discussion of para¬ 
metric functions includes applications of 
parametric cubic, Bezier, and B-spline 
functions to the description of curves and 
surfaces. Material related to geometrical 
transformations includes homogeneous 
coordinates, translations, rotations, pro¬ 
jections, and symmetry groups. Finally, 
computational geometry ideas include 
tests for intersection and formulas for 
computing distances, areas, volumes, ori¬ 
entations, and curvatures. 

The author chose to describe the sim¬ 
plest, most direct way to work in two and 
three dimensions. This book is short on 
proofs, derivations, and justifications, 
and general results are not emphasized. 
One page, for example, shows methods 
for computing the determinants of matri¬ 
ces of rank two and three, but shows no 
method for computing the determinants 
of higher rank matrices. 

Naive or picky readers should beware. 
This is a book about mathematics for 
programmers. The text states that “a ma¬ 
trix is a complex number.” The sentence 
is clearly aimed at programmers discov¬ 
ering matrices for the first time; it 
means that matrices are objects, like 
numbers, for which an arithmetic can be 


defined. Similarly, the author assumes 
that readers know about programming. 

The text claims that the root of a nonlin¬ 
ear equation is found with Newton’s 
method when successive iterates are 
equal; programmers should read this to 
really mean that the algorithm stops 
when the difference between successive 
iterates is less than a predetermined 
threshold. 

Readers will need enough of a calculus 
background to know what a derivative is 
and how to differentiate a polynomial 
function. They will need enough algebra 
to know what a binomial coefficient is 
and how to solve a set of simultaneous 
linear equations. They’ll also need to 
know where to look for more detailed in¬ 
formation because this book does not 
contain a list of references. 

Numeric examples throughout the 
book show each concept “in action.” 

Computer Graphics Handbook does a 
better job than many others of illustrat¬ 
ing the range of mathematical tools 
available to a geometric modeler. Many 
books present the same topics, but few 
present the same topics together or tailor 
their presentation so well to the needs of 
computer graphics programmers. In par¬ 
ticular, few books illustrate the princi¬ 
ples of parametric functions so clearly as 1 

this handbook does, and many leave out 
the discussions of symmetry functions 
that are included here. 

The mathematical exposition is not 
deep, but it is broad. Even so, the author 
retains enough specific detail to make his 
material immediately useful. 

This book is an enjoyable source of 
ideas, a memory jogger, and a study 
guide for newcomers to the field of com¬ 
puter graphics and old hands alike. 

Leon Tabak 

Cornell College, Mount Vernon, Iowa 
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Handbook of LAN Technology 

Paul J. Fortier (McGraw-Hill, New York, 1989, 551 pp., $59.95) 


The decreasing cost of workstations, 
the consistently high cost of peripheral 
devices, and user requirements for high 
performance and reliability indicate that 
distributed systems are becoming more 
and more important. These systems are 
developed with local area networks 
(LANs) as their backbones. 

A LAN is the basic computer-system 
resource that allows users to share all 
other computer resources. LANs have 
become a central component of the com¬ 
puter resources of almost every research 
institution, school, university, industry, 
and company. This has resulted in a wid¬ 
ening group of professions that need to 
understand LAN theory and technology. 

In the words of the author (in practice, 
the authors, because seven researchers 
made contributions), this book is intend¬ 
ed both “to provide a solid foundation in 
the technology utilized in the design and 
use of LANs” and to serve “as a concise 
source for the pertinent information the 
user, designer, or manager of LAN sys¬ 
tems is required to know in the perfor¬ 
mance of his or her job.” 

This book will be appreciated by peo¬ 
ple who are responsible for computer 
equipment maintenance and those who 
make purchasing, company planning, 
and development decisions. Some sec¬ 
tions may also benefit students, teachers, 
computer systems designers, and archi- 

The Handbook, which consists of 
eight parts with various chapters and 
sections, is fairly self-contained and 
does not assume any previous experi¬ 
ence in LANs. However, certain sections 
dealing with analytical models and the 
analysis of LANs and token bus distrib¬ 
uted systems (Sections 17.2 and 17.3) 
require a basic knowledge of probability 
concepts and queuing theory. Also, the 
book does not rely on references. A 
handbook of this type should broadly 
cover all aspects of LAN technology, 
but not in depth. It should also allow the 
interested reader to identify the best ref¬ 
erences, which is important to students. 

Some of the book’s parts are interre¬ 
lated, while others are nearly self-con¬ 
tained. The first part defines LANs and 
shows why, how, and where they can be 
applied. It features an overview and ba¬ 
sic explanation of LANs and identifies 
organizational, financial, and technical 
benefits from using them. Part 1 also 
provides the background for the main 
design and selection issues in subse¬ 
quent sections. 

When dealing with LAN specifics, the 


following issues are addressed in Parts 2 
through 4: transmission media, topology, 
signaling techniques, error management, 
and medium-access protocols. The cov¬ 
erage and presentation of these issues 
are not satisfactory. Some topics are dis¬ 
cussed twice (for example, transmission 
media, topologies, and routing), whereas 
others (for example, signaling tech¬ 
niques) are discussed marginally. 

Part 2 deals with communication tech¬ 
nology. It repeats some aspects present¬ 
ed in Part 1 (architectures, media, and 
network interface unit), but it does not 
examine signaling techniques. However, 
error management is presented satisfac¬ 
torily. 

The following part addresses LAN to¬ 
pology. Based on this material, novice 
readers would think that the most com¬ 
monly used topology is a mesh topology. 
They would be very surprised to find 


The scope of this book is 
very wide and, because of 
this, many different readers 
will appreciate it. 


that this is not reflected in the real 
world, as characterized in Chapter 24 
and the tables in Section 5.8. Readers 
would also think that topology is the 
main issue when designing or selecting a 
LAN — and that it can be automatically 
generated. I think that a handbook on 
LANs should not be dealing with auto¬ 
mated topology generation at all. 

Part 4 adequately presents medium- 
access protocols and LAN routing and 
addressing, and properly characterizes 
LAN interconnection standards. To ac¬ 
cess information, LANs can be attacked 
passively and actively by both illegiti¬ 
mate and legitimate users. This creates a 
need to understand LAN security aspects 
and the countermeasures that can be tak¬ 
en against security threats, which the 
next part covers. 

Here, a good presentation of the role 
of encryption, cryptosystems in use, and 
key management is included. The dis¬ 
cussion of authentication and its place in 
LAN security allows the reader to iden¬ 
tify its importance and the basic ap¬ 
proaches used. 

Next, the author presents information 
on LAN performance. Included are LAN 


modeling and analysis using analytical, 
simulation, and empirical modeling. 

This part features a good discussion of 
elements that should be taken into con¬ 
sideration when characterizing LAN 
performance by quantitative values. 

Fortier then discusses selected as¬ 
pects of operating systems for LAN- 
based distributed systems. He introduces 
only the basic concepts of such operat¬ 
ing systems, the client server model, and 
object and remote procedure call mod¬ 
els. He also very briefly characterizes 
the basic aspects of systemwide re¬ 
source management and naming and 
load balancing and scheduling. Howev¬ 
er, a reader would have some problems 
in seeing the logical architecture of a 
distributed operating system, its associa¬ 
tion with the LAN protocols, and most 
design issues for this class of operating 
systems (that is, homogeneity, heteroge¬ 
neity, interdependence, interprocess 
communication, and so forth). These 
subjects are covered too briefly. 

The last part of the book presents ele¬ 
ments of LAN architecture, repeating 
some issues addressed in previous parts. 
It also examines LANs in use and their 
current implementations. The two ap¬ 
pendixes contain a vendor list and a bib¬ 
liography. The bibliography contains 
unexpected references (for example, da¬ 
tabases, which are not mentioned at all 
in the book), but does not list two im¬ 
portant texts, Local Area Networks — , 
An Introduction (W. Stallings, Macmill¬ 
an Publishing Company, 1987), and Lo¬ 
cal Networks (W. Franta and I. 

Chlamtac, Lexington Books, 1981). 

As a teacher of computer networks to 
both undergraduate and graduate stu¬ 
dents, I think that this book would only 
be useful as a reference for LAN cours¬ 
es. If used, a teacher would first need to 
provide adequate context and back¬ 
ground material on design and standard¬ 
ization issues. 

The scope of this book is very wide and 
covers all aspects of LAN technology, 
and, because of this, many different read¬ 
ers will appreciate it. I did not observe any 
technical errors, and the information is up- 
to-date. However, because of the many 
contributors, this book suffers from repeti¬ 
tion and lack of careful ordering. These 
are minor criticisms — it is very easy to 
criticize such a big book. The whole work 
will be appreciated by a wide cross section 
of professional readers. 

Andrzej Goscinski 

University of New South Wales 


April 1991 
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Confessions of a used-program salesman 

— Will Tracz 


IPLing the system 

All is not well in reuse land. It seems 
that while the elves were busy at their 
workstations, cutting and pasting reus¬ 
able software pieces together, some 
grinch sneaked in and IPLed the system. 

The results were disastrous; the reuse 
libraries were scrubbed clean. Nothing 
was spared from the massive purge. 

Not only were the programmers 
stripped of the tools of their trade (source 
code to hack), but most of the documen¬ 
tation was gone, too. Worst of all, some 
programmers were found to be contami¬ 
nated and had to be quarantined! (The 
doctor says they’ll be OK in a couple of 
years if they stay away from the kind of 
software that caused the problem.) 

Just when I thought things couldn’t get 
worse, they did. Someone told me that I 
couldn’t sell and reuse a program that I 
designed and wrote two years ago (after 
extensively surveying the literature, I 
might add) because someone else had the 
idea three years ago — and just got 
around to publishing it today. I wanted to 
cry foul, but all I could do was cry, once 
I knew what I was up against. 

That frightening experience left me 
paranoid and a bit more conservative in 
my ways. 

Does this sound far fetched? Have I 
been hitting the bit bucket a little too 
hard lately? I only wish that were true. 
Unfortunately, this is an all-too-real sce¬ 
nario. In my case, IPL does not stand for 
“Initial Program Load,” as us old bit 
twiddlers learned, but “Intellectual Prop¬ 
erty Law.” The grinch that stole the used 
programs is an IPL lawyer armed with an 
injunction. 

This scenario is quite relevant to soft¬ 
ware reuse, especially when the software 
comes from unknown sources. There is 
an old saying about assuming something 
to be true. In this case, you can get into a 
lot of trouble if you assume that a piece 
of software is in the public domain. You 
really need to carefully establish how a 
piece of software came into being, or 


else you can be in for a big surprise. 

There are other old sayings about “get¬ 
ting what you pay for” and “the best 
things in life are free.” Well, in this case, 

I believe the saying “if you see it lying 
on the street, don’t pick it up” is much 
more appropriate. 

Reusing software verbatim requires 
making a copy. Copying software is not 
always legal, as most everyone knows. A 
problem occurs when someone modifies 
or reuses part of (or all of) someone 
else’s software or uses the design as a 
basis for new software. In either case, the 
software can be viewed as a work de¬ 
rived from the original; hence, all rights 
to the work belong to the original creator 
— except what was added. Also, trans¬ 
lating software from one language to an¬ 
other can be considered creating a deriv¬ 
ative work; therefore, it is also illegal 
(assuming you did not get authorization 
to do so or did not write it from scratch 
in the first place). 

Things get even worse. For instance, 
creating a plug-compatible piece of soft¬ 
ware without even looking at someone 
else’s code (using a black box approach) 
can even cause litigation. Unfortunately, 
merely looking at someone else’s source 
code (whether you have it or decompile 
it and whether you think it is in the pub¬ 
lic domain or not) may reveal something 
that later turns out to be a trade secret, in 
which case you run the risk of being ex¬ 
cluded from developing similar applica¬ 
tions for a period of time in the future. 

I’ll tell you one thing for sure: I am all 
for intellectual property rights, but now 
that I know more about them, I have be¬ 
come extremely cautious. Before, I never 
used to look a gift piece of reusable soft¬ 
ware in the mouth. Now, I really check 
its pedigree. 

Reflections on the times 

April first can bring out the “wurst” in 
some people (who said I don’t relish the 
chance of being a hot dog). Since this is 
the eighth anniversary of my first “con¬ 


fession” in Open Channel, let me reflect 
on the progress, or lack thereof, in the 
state of the art of computer science (is it 
an art or is it a science?). 

I have often felt that software engi¬ 
neering is an immature technology, due 
in part to the relatively rapid advances in 
our lifetime. I’ve also wondered if what 
is immature about our profession is the 
people, not the technology. 

As required for all electrical engineer¬ 
ing graduate students at Stanford Univer¬ 
sity, I recently attended a very enlighten¬ 
ing lecture by a prominent psychologist. 

After analyzing several hundred com¬ 
puter professionals (there seem to be a 
lot of strange people in Silicon Valley), 
the psychologist came up with a very re¬ 
vealing personality profile that fits most 
programmers and engineers. He found 
that computer people are (1) perfection¬ 
ists and (2) like to be in control. He also 
found that during their childhood they 
were overprotected and were never al¬ 
lowed to do things for themselves — or 
they grew up in total chaos. 

A computer program is one example of 
perfection. As for control, a programmer 
has complete control over both the state 
and operation of a computer being pro¬ 
grammed, and an engineer has complete 
control over the hardware being built. 

This power is gratifying, yet not al¬ 
ways transferable to the real world, 
where we have very little control over 
our personal lives. Hence, socially devi¬ 
ant behavior emerges, like workaholism 
(not that I personally find anything 
wrong with that, but my wife might). 

The temptation to be omnipotent and 
to take control by hacking someone 
else’s software could be an example of 
this personality trait. This, coupled with 
software’s lack of physical properties, 
makes hacking a seemingly victimless 
crime. 

As we and the profession mature, I ex¬ 
pect that we will be better able to disci¬ 
pline ourselves and the process of soft¬ 
ware development. Until then, we will 
hack away at the problem, and the prob¬ 
lem is us. 
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Sponsored by the IEEE Engineering in Medicine and Biology Society, the IEEE 
Computer Society and the IEEE Baltimore Section. 

The Symposium 

The Symposium is intended for engineers, computer scientists and physicians 
from academia, industry and government who are designing and developing 
computer-based medical systems (CBMS). 

The Program 

CBMS combines technical papers, poster presentations, panel discussions, 
tutorials and tours. Both contributed and invited papers will be presented 
assuring an excellent and balanced program. Six tracks related to Computer- 
Based Medical Systems are planned: 

• Clinical Assessment and Risk Evaluation : real-time signal processing, 
database systems 

• Medical Device Reliability and Safety : fault-tolerance, device testing, 
validation and software safety 

• Medical Image Processing : networking, compression, enhancement, 
modeling, simulation, PACS 

• Emerging Cardiovascular Technologies : monitoring, imaging, bioimpedance 
measurements, microcomputer applications, cardiopulmonary resuscitation 

• Neural Networks and Expert Systems : theory, implementations, pattern 
recognition, applications 

• Prosthetic Devices and Speech Aids : environmental control, word 
processing, devices for the hearing impaired and vision impaired, 
standards 

Poster sessions, software demonstrations, and a tutorials program are also 
planned. 

Registration 


Important Information: 

Member IEEE 

Advance Registration 
before April 12,1991 
$200 

At Symposium 

$240 

Non Member 

$250 

$300 

Student 

$50 

$65 


Registration fees include sessions a copy of the Symposium proceedings, the 
Sunday evening reception and all breaks. Guest tickets for the reception may be 
purchased at the Registration Desk. 

Lodging 

Rooms are available at the Symposium Hotel at special rates. Hotel 
reservations should be made directly with the Stouffer Harborplace. The phone 
number for reservations is (301) 547-1200. 

Additional Information can be obtained by contacting Jeffery Lesho, The Johns 
Hopkins University, Applied Physics Laboratory, Bldg 13-S112, Johns Hopkins 
Rd., Laurel, Md 20723-6099. Email can be sent to: lesho@aplcomm.jhuapl.edu. 
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USENIX SUMMER 1991 TECHNICAL CONFERENCE HD0 


MULTIMEDIA— FOR NOW AND THE FUTURE 


’«* What are the technical engineering requirements that will enable 
operating systems to support and deliver the new types of interfaces— 
voice, video, animated graphics, touch and music—that users are 
demanding now? 

"* What must you, and your organization, do to meet the challenge of 
multimedia? 

"* How do we design new multimedia interfaces to improve information 
handling? Which projects, underway now, offer insight into the 
directions to be taken in developing fully integrated multimedia systems? 

These are some of the questions tackled by presenters and attendees at the 

USENIX Summer 1991 Technical Conference and Exhibition. 


IS VARIETY OF FORUMS 


USENIX Summer 1991 Conference participants will explore general 
operating system and environment questions as well as address the 
conference theme: Multimedia— For Now And The Future. 


SI PLAN NOW TO ATTEND BDl 


USENIX SUMMER 1991 
TECHNICAL 
CONFERENCE 
& EXHIBITION 

June 10-14,1991 

Opryland Hotel ❖ Nashville, Tennessee 


PEER-REVIEWED PAPERS 

Original work in operating systems and environments and discussion of the 
engineering requirements to support and deliver multimedia systems, particularly 
experiences with integrating voice, video, audio, touch and music. 

TUTORIAL PROGRAM 

Hands-on tutorials by leading experts focus on multimedia, as well as additional 
topics essential to UNIX, UNIX-like and advanced computing systems and the 
C programming language such as: 

■♦Writing Applications with OPEN LOOK ■*TCP/IP Protocol Suite 
■♦Advanced Systems Administration "■* Network Security 

■* Programming with X Toolkit Intrinsics "* Programming X Window 

«* Internals of UNIX System V Release 4.0 •* Using C++ Effectively 

PANEL DISCUSSIONS 

Protection of Software Intellectual Property, Window Systems and The Far- 
Reaching Possibilities of Location-Independent Computing are three of many 
topics of interest currently under review. 


MULTIMEDIA PRESENTATIONS 

State-of-the-art demonstrations of new, exciting 
work in multimedia on UNIX. 

INVITED PRESENTATIONS 

Potential topics include, among others: systems 
administration, software engineering techniques 
and security. 



Opryland Hotel 

Spacious facilities of the Opryland Hotel 
allow the entire program of technical sessions, 
tutorials, concurrent sessions and vendor 
exhibition to take place under one roof— 
a priority with USENIX conference 
and exhibition-goers. 


IS USENIX 


the UNIX "and Advanced Computing 
Systems Professional and Technical organization, is a 
not-for-profit association dedicated to 
™* fostering innovation 

»♦ communicating technological developments, and 
sharing ideas and experience relevant to UNIX, 

UNIX- related and advanced computing systems 
“♦ providing a forum for the exercise of critical 
thought and airing of technical issues. 


IS PROGRAM COMMITTEE HD SI 


TECHNICAL PROGRAM COMMITTEE 
Chair: Deborah K. Scherrer, mt Xinu 

Eric P. Allman, University of California, Berkeley 
Frances Brazier, Vrije Universiteit 
Tom Duff, AT&T Bell Laboratories 
Daniel E. Geer, Digital Equipment Corp. 

Stanley P. Hanks, Baylor College of Medicine 
Michael Hawley, MIT Media Laboratory 
Jun Murai, Keio University 
Alan G. Nemeth, Digital Equipment Corp. 

Jeff Peck, Sun Microsystems 
Charles E. Perkins, IBM T.J. Watson Research Ctr, 
Gretchen Phillips, SUNY Buffalo 
Charles S. Roberts, Hewlett-Packard 
Larry Stead, Bellcore 
Avadis Tevanian, NeXT, Inc. 


INFORMATION SD1 


MORE CONFERENCE 
INFORMATION 

Please contact: 

USENIX Conference Office 
(714) 588-8649 
FAX (714) 588-9706 


a registered Trademark of UNIX System Laboratories, Ind 


























































